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.
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…
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.
@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.
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.