Native Qobuz update

Hi @Netsrot,

I can’t talk for other manufacturers on what they consider as acceptable on streaming stability, but for Naim the eDMP3 is not really suitable for handling internet network streams above 1Mbit/sec with a network link that may have typical consumer internet latency on it. Tidal was pretty much pushing the bounds for eDMP3 and as you will see from this forum, various customers suffered from intermittent dropout issues due to it being sensitive to internet network latency from the product to Tidal’s CDN.

So why is it sensitive?
The Bridgeco Streaming IC was designed in a day where there was no lossless or highdef streaming and the silicon designers put compromises in the Ethernet PHY and DMA memory meaning that it couldn’t handle large TCP windows without dropping data on reception. Large TCP windows are vital for highdef streaming so large chunks of data flow from the CDN to product and this makes it latency insensitive.

On a local LAN streaming it is not really a problem as network latency is low and doing lots of 6KByte receives and relevant ACK’s can work fine For example doing 125x 6KByte chunks (for a 6Mbit stream for a typical Qobuz 24/192 FLAC file) requires a network latency less than 8ms. On a wired network that will easily be achieved. However, to achieve an 8ms ping time from Qobuz’s CDN is pretty unlikely to happen. In practice customers often have 20-70ms depending on time of day and route to CDN. At around 60ms FLAC 16/44.1 will start to drop out as the data can’t be received quickly enough due to the round time trip of receiving 6K, acking it, getting another 6K. for those who fancy a geek-out, this online calculator proves the point: Network Throughput Calculator - WintelGuy.com

As it’s a physical limitation in the silicon there is no magic to fix it. There are workarounds as discussed by various on this forum, as some UPnP servers support Qobuz,

On the new range of products we designed them with high def streaming in mind and hence blessed them with MIMO 802.11ac wifi, good ethernet PHY’s and lots of RAM for burst downloading streams from the internet.

Overall, this really was a case of it’s technically unsound to attempt it. As a lead Bridgeco customer we have a lot of inhouse knowledge on this platform and pioneered many features on it (Apple Lossless, 192kHz support, DSD for example). We were the manufacturer who worked directly with the Bridgeco sw stack team (that’s not Audivo) to optimize the ethernet PHY code so Tidal worked better. Other smaller manufacturers then gained the benefits of our work over time for their products.

With regards

Steve Harris
Software Director
Naim Audio

10 Likes