When I play the 4 second RME bit perfect test files (different bit depth and sample rates) the 1st play plays (and passed the bit pefect test).
But when asking Roon to repeat/loop one track (like if I need more than 4 seconds of confirmation for bit perfect testing) Roon pauses. Loop one track.
Is multiple 4 seconds track lengths too short for Roon to handle for ‘repeat one track’?
I have Roon Server running on macOS and testing to an iOS Roon endpoint and direct USB.
Can you reproduce this?
Just pick one and choose repeat one track, let it loop?
I don’t have this issue with simple VLC media player on macOS.
FWIW, I’m not able to get Roon to play a single 4 second track more than twice when the queue is set to single-track repeat. It may be system-dependent, but the shortest track that I can get to repeat indefinitely is six seconds. Five seconds did not work either.
My Core is a ROCK build running on a 7th gen i5 NUC. Wired 1 Gbps Ethernet for Core and Outputs.
Sounds like exactly the same issue.
Thanks for reproducing.
Does it work if you add multiple 4s files to the queue?
I kinda remember discussing this with @brian and concluding it was a strange corner case and that it wasn’t worth complicating the code to support… But that might have been Sooloos… I’ll let him remember for me…
Multiple 4s tracks on repeat seems to work for me.
Does not work for me.
There are 9 RME test files, each 4s. Different bit depths and sample rates.
If I try to play this playlist, stops after first or second track
Then Roon hangs.
Works with VLC Media Player on macOS
I’m not 100% sure I turned on repeat one, but I think I have and it worked for me for Roon - Lumin USB output to RME in November 2020, when a user asked about 32-bit PCM through a Lumin.
No worries. Repeat one failing for me and David here with 4s track
In my system, repeating a single track does not work with the USB-connected DAC (RME), but works with a network-connected DAC.
For me it fails with both direct USB connection and with iOS Roon app endpoint (connected to same DAC via USB).
@danny’s recollection is right. This edge case is difficult to support across the ~10 different audio streaming protocols that we support (some more than others). It could probably be fixed in some cases, but the effort / reward tradeoff on work like this means that it hasn’t been a priority.
I guess the horse has bolted, so a fix is too hard at this point.
But how is it broken in the first place? A 4s track loop can’t work?
Things get pretty funky when tracks are shorter than the network buffer sizes in various parts of the system, and the interactions vary by audio device. It becomes a topic that has to be handled as its own thing amidst a field of stuff that is device-agnostic.
This is probably why its breaking for @dabassgoesboomboom but works for @David_Snyder in the 4s tracks queued up.
If you must have this specific “test audio”, use Audacity or any other audio software to stitch together this track with multiple copies of itself.