Qobuz occasionally serves a 5.1 source track, examples below. We have a stereo player so downmixing to 2-track is happening. This is giving frequent dropouts (to the point where it is unlistenable).
Describe the issue
We have recreated this issue on a Linn endpoint; using an iPad as an endpoint; using a LUMIN D1 endpoint; and on another user’s system by @CrystalGipsy.
It would be best if we could get the 5.1,conversion to work; but an alternative would be a settings option to stop Qobuz sending 5.1 content.
Describe your network setup
Ubiquiti network (UXG-Pro, 24-port managed switch). Roon Server version 2 build 1490 running under DietPi on Intel NUC. Linn Klimax and LUMIN D1 on wired network; iPad on wifi.
Since processing speed in typically > 50, it suggests that the issue is something other than server performance.
The logs may provide an insight, but I’d say it’s probably network related – when I’ve seen slow loading media messages, it’s usually that or a firmware update needed some intervention.
Same issue here but is a Roon problem only, same stream pulled using other server software and streamed via LMS has no problem to same devices it’s also converting to PcM in my scenario. If you look at logs Roon reports it can’t download it quickly enough and says it’s slow connection and in bad case buffer issues with sleep in preread errors. This is server side not to endpoints.
Yet exact same url used by roon to stream it can be copied and pasted from Roons log into a web browser and plays without a single problem straight away. Notice that Roon has quite a delay before it even starts to play. This seems to be a Roon problem to solve.
Different DNS make zero difference so let’s rule that out straight away. It seems to be a limitation of Roons code if others can keep up and not suffer same issue. It’s not network related either. As server can pull full internet bandwidth. I can even stream the same file via LMS so the endpoint is pulling it not the server and this is on WiFi or one on wired.
You mentioned a managed switch between your roon Server and the Linn. Though, in your case ir’s not RAAT but Linn streaming protocol you may try enabling “flow control” in your switch for the affected network ports. This is at least quite import in case of using RAAT. Don’t know how it’s with Linn, though.
All assuming it’s not the Qobuz streaming connection.
No processing speed shown, this is not the issue anyway,. Its server side not being able to download it quickly enough for Roon to buffer it before sending it out thats the problem shown in the logs. How long did you play them for as its pretty intermittent in my usage of them. Sometimes it plays through ok others not. But via any other means it doesnt drop a beat. I even managed to download the stream Roon couldnt stream in 2 secs via my browser.
Does seem to be very intermittent as played fine for a while then it starts. So could be the load on Qobuz or VM bandwidth drops so much it cant pull it. The latter I doubt as I would have other issues I dont see. I could also stream perfectly fine to another device without any issues via LMS at same time Roon couldn’t.
For me I get this when it starts to drop
2/20 14:13:10 Debug: [RaatSender] [prebuffer] sleeping in read – this isn’t good
which is Roons way of saying it cant load it from the internet quick enough to buffer for playback out. Why does Roon have this problem, when I can play the exact same stream its pulling direct on pc in a browser, this has no buffer it just plays it straight away and doesn’t drop a beat. LMS on same server has no issue pulling the stream and works perfectly fine and its transcoding it and this is to any zone wired or wifi. What is is it that makes Roons netcode choke? Its not as if its taxing my internet at all at 20mb/s top yes Roon cant sustain it for long where all others can.
Yes, as it does the same to any RR devices that don’t give you buffer options. The issue is before it even gets to the output stage as its choking as Roon cant get it off the internet quickly enough, oddly its playing fine at moment after its gets past the first few tracks which always cause it an issue.
In logging for this specific case, the sample dropouts accumulate during distribution - the endpoint is reporting packet loss to RoonServer after the file has already been downloaded and processed by the server. This packet loss eventually overwhelms the audio stream at the RAAT level.
That isn’t direct evidence of @CrystalGipsy’s inquiry into whether the downloader handles large files from Qobuz efficiently. We’ll need to investigate that question separately with development, so we’ve made an investigative ticket as such.
Roon doesn’t have the ability to request a different version of the catalog object when API servers up multi-channel. Roon can restrict the format in Settings → Services, but there are catalog-level blockers to distinguishing between 5.1 and stereo content with a toggle switch setting at this time.
We will keep this thread open to investigate the download of 5.1 files from Qobuz as a potential vulnerability since that issue has come up here.
Thanks Connor. I am doing some more nvestigating my end to see if I can mitigate it in any way with different setups. Will let you know any more findings my side.
Not every endpoint has them, none of my Roon Ready devices (Naim and Wiim) do. And with RAAT I suppose it has to be that way because hardware buffer size differs by device and you would force multi-room to de-sync if buffers differ.
