advertisement


Streaming: Qobuz, DLNA, UPnP etc

That makes sense. My understanding is a DLNA renderer is pretty dumb. It wants an instruction and location. Go here, play this. It wouldn’t have a clue what an album was. Early ones couldn’t even cope with gapless and glitched, paused or popped if given what I assume is an immediate ‘play’ instruction and location for the next track. MConnect has a ‘gapless to renderer’ option that the DSX understands fine. I think this is a pretty neat solution as it means the control surface isn’t in the data loop, it only monitors and sends follow-up commands.

Problem is that with the mconnect out of the streaming chain you have no buffering/caching available to deal with errors or glitches from Qobuz.

Roon may have helped you, because of the way it handles grouped or multizone playback it streams (RAAT) to the endpoint much more "realtime" as it doesn't allow the client to buffer Had a look at Roon partners page and unfortunately the DSX is not certified so you wouldn't be able to use RAAT.

I'd give Audirvana a trial, that supports DLNA and will buffer the audio before sending it to the DLNA client. That may alleviate the issues having the DSX and Qobuz going direct, as it now sits in the streaming chain.

Also has IMHO the added bonus of sounding much better than Roon or other playback clients/software.

Also I'd try the test of unplugging the NIC on the DSX multiple times to see what sort of buffer it has, if you only tried it once or twice the buffer may well have been close to empty when you unplugged and that's why you only got around 1sec. Try it again but do it at least 10 times and see what you get?
 
Pointing a finger at Qobuz servers doesn't help cure the problem, though. In practice it seems to be about finding a client that does better in applying the "be liberal in what you receive" end of the robustness principle. Either that or switch to a service that is more robust at it's end (as Tidal appears to be from the report above).

It would be interesting/useful if we could find the area of non-compliance to UPnP/DLNA standards that is tripping-up some older streamers. The thing I find so frustrating is not understanding the failure mode, this being what sent me down the network bandwidth rabbit-hole. I made the mistake of assuming what was being broadcast was standards compliant both from a TCP and higher level. If not I really can’t blame the DSX for choking. It is just a DLNA renderer, give it something outside of that and I can’t blame it for dropping or misinterpreting a command.

Problem is that with the mconnect out of the streaming chain you have no buffering/caching available to deal with errors or glitches from Qobuz.

The absolutely rock-solid nature of Tidal has to my mind ruled out that as the fault condition. I think you were far closer when you suggested something upthread about malformed TCP sessions or whatever relating to Qobuz. I suspect I dived down the wrong hole focusing on my network.

Tidal has not had an issue yet. It works. That suggests it is doing something differently somewhere. I’d like to know exactly what! Regardless whatever it is has lost Qobuz an annual subscription. I was ready to send them £130 for a whole year upfront. Tidal won purely by working.
 
The absolutely rock-solid nature of Tidal has to my mind ruled out that as the fault condition. I think you were far closer when you suggested something upthread about malformed TCP sessions or whatever relating to Qobuz. I suspect I dived down the wrong hole focusing on my network.

Don't think it is malformed TCP but more the way your client handles the streams. Qobuz works by breaking the audio file down into chunks and sending them over a TCP connection in groups. It sends a header or information packet and then 11x packets of audio, then another info packet and 11x packets of audio and so on etc.

It should use the same connection i.e client port to stream everything but sometimes clients have issues keeping it open/stable and will just close the connection. I saw this with my own client and it just sends a TCP RST to say I've closed this and the server will then open a new connection.

I managed to get a stable packet capture with Qobuz just now and it has used a single port to download 78MB of audio without any tcp errors.

I suspect that your DSX was Chord's first foray into streaming and they didn't get the tcp/ip stack quite right when they implemented the stream700 platform.

If you're happy with Tidal then it's case closed but yes :) I was trying to push you away from getting bogged down with latency or bufferbloat as they will very rarely be issues on home networks (unless you are a heavy gamer or upload real time stuff)
 
Interesting about the bufferbloat - I'd never heard of it before, and not had any apparent issues with my network/internet.
A little experimenting today (it's been raining all day...), and the waveform site: https://www.waveform.com/tools/bufferbloat
gave me a solid F...

https://speed.cloudflare.com/ gave me:
Video Streaming: Average
Online Gaming: Poor
Video Chatting: Average

I have an older TP-Link V900 router which doesn't have SQM. But it does have QOS. I enabled it and put my max download/upload speeds into the settings. Reran the tests and got an 'A+' from waveform and 'Great' for all three cloudflare categories.
Toggling QOS on and off gives 100% repeatable results.....so I guess I'll leave it on for now. Can't imagine I'll notice much difference, I'm not a gamer.
 
It would be interesting/useful if we could find the area of non-compliance to UPnP/DLNA standards that is tripping-up some older streamers. The thing I find so frustrating is not understanding the failure mode, this being what sent me down the network bandwidth rabbit-hole. I made the mistake of assuming what was being broadcast was standards compliant both from a TCP and higher level. If not I really can’t blame the DSX for choking. It is just a DLNA renderer, give it something outside of that and I can’t blame it for dropping or misinterpreting a command.



The absolutely rock-solid nature of Tidal has to my mind ruled out that as the fault condition. I think you were far closer when you suggested something upthread about malformed TCP sessions or whatever relating to Qobuz. I suspect I dived down the wrong hole focusing on my network.

Tidal has not had an issue yet. It works. That suggests it is doing something differently somewhere. I’d like to know exactly what! Regardless whatever it is has lost Qobuz an annual subscription. I was ready to send them £130 for a whole year upfront. Tidal won purely by working.
This coul be perhaps that Tidal's turnover is around 8 times that of Qobuz? More server redundancy, more resilient network, et al, as they have the resources. This could reduce latency, which seems more crtical in your set up than others

If you're in to Jazz then Qobuz reigns supreme, especially for artists and albums more off the beaten highway.
 
The absolutely rock-solid nature of Tidal has to my mind ruled out that as the fault condition. I think you were far closer when you suggested something upthread about malformed TCP sessions or whatever relating to Qobuz. I suspect I dived down the wrong hole focusing on my network.

Tidal has not had an issue yet. It works. That suggests it is doing something differently somewhere. I’d like to know exactly what! Regardless whatever it is has lost Qobuz an annual subscription. I was ready to send them £130 for a whole year upfront. Tidal won purely by working.
Are you able to stream via the Tidal app or are you still using a 3rd party app?
 
This coul be perhaps that Tidal's turnover is around 8 times that of Qobuz? More server redundancy, more resilient network, et al, as they have the resources. This could reduce latency, which seems more crtical in your set up than others

Interesting point, though I’ve no idea. I‘d certainly pick Qobuz if everything else was equal as I think it sounds better and it seems to have far more high-res.

Are you able to stream via the Tidal app or are you still using a 3rd party app?

I’m still using MConnect. The Tidal iOS app, like the Qobuz iOS app, doesn’t seem to have DLNA functionality, which I find far beyond bizarre.
 
...
I’m still using MConnect. The Tidal iOS app, like the Qobuz iOS app, doesn’t seem to have DLNA functionality, which I find far beyond bizarre.
The Qobuz app on a PC did at one time have DLNA (marked as experimental, IIRC). The app saw my DLNA end-point but never managed to connect properly. However it disappeared from the updated PC app quite a while ago. I really do wonder if they are operating on a shoestring and are not devoting resources beyond what is essential.
 
The Tidal iOS app, like the Qobuz iOS app, doesn’t seem to have DLNA functionality, which I find far beyond bizarre.
They'll probably want the customer experience to be a little better than what you've gone through in getting it to work!
 
The Qobuz app on a PC did at one time have DLNA (marked as experimental, IIRC). The app saw my DLNA end-point but never managed to connect properly. However it disappeared from the updated PC app quite a while ago. I really do wonder if they are operating on a shoestring and are not devoting resources beyond what is essential.

They'll probably want the customer experience to be a little better than what you've gone through in getting it to work!

Or they looked at the use cases and decided that such a small percentage of users want DLNA it just didn't justify the development or investment.

Bit like Spotify Supremium, read the other day that spotify did a survey and have dropped HiFi as the vast majority don't want it or won't pay more for it.

Most of them just release an API to access their platform and let the 3rd party handle the DLNA/UPnP (or whatever) integration they want.
 


advertisement


Back
Top