Because to do that they would need to incorporate MQA decoding software, and full decode or unfold is somewhat involved… I guess Naim feel there isn’t enough customer demand or SQ benefit to warrant, especially as they now have Qobuz for full lossless hidef.
Steve Harris gave the Naim position last year, it was open to change as you’ll see.
I hear what you are saying. I went from Spotify to Tidal and continued to Qobuz in my quest for better SQ.
Don’t manufacturers who want to implement MQA, also have to give MQA full blueprints and schematics of their equipment? I have heard this before.
If so, it’s understandable Naim doesn’t wan’t to give away trade secrets to MQA.
3 months on and I’ve finally got to find my way around Mconnect. Working well sound wise except with Hi Res 196 kHz Qobuz files. Dropout is so bad its unlistenable and it doesn’t make sense. I have reasonable wifi at 23 mps download speed. (4k Netflix is perfect). Taking a hi res album I’ve bought and have on my NAS drive, it works perfectly on my Naim NDX at 196 kHz. Also perfect straight from my iPhone Qobuz to headphones via Drafongly red. Works perfectly with with Mconnect at 92 kHz , but drops out at 196. Very annoying as I cant make the most of my Qobuz hi res plan. Any ideas?
I am not the best adviser, as I stream only locally.
Some use Bubleupnp on Nas and stream like that on their old Naim streamers.
There are plenty of threads for Qobuz and old streamers…
I presume you mean that 96 works but 192 doesn’t.
I have no experience of Mconnect, and I can understand your frustration when things don’t work, but to my ears, all the 24 bit material on Qobuz sounds good. I can’t really hear any difference between 24/192 and 24/96. Even 24/48 sounds pretty good. I would just set Qobuz to 24/96 max. and enjoy it.
Thanks for replies. I will set Qobuz at 24/96 max on Mconnect. I can only hear the slightest improvement at 192 (which only works with dropouts). I’m just mystified as to why this happens when the NDX copes on the local network and the NAS and the iPhone streams it Ok from the Qobuz app to DAC and headphones.
Back to the older Streamer like NDX, NAC 272/172 and hole Uniti-lineup with the Audivo Streamer Board (24/192), I still don‘t understand why they should not be ok for Qobuz. Cyrus had done this in 2018 for streamline 2 and similar products. And they all share the same Streamer Board (SeDMP3, FCC-ID: ZUCSEDMP3 ) from the German Company Audivo, which is in Naim, Cyrus, T+A and Electrocompaniet products of this time. From streamline 2 and UQ2 I know that these boards are 100% identical. So I think Naim is just not willing to support older Streamers. There is NO technical reason. Maybe they have to pay to much to the Germans for the firmware development, which is mostly already done for Cyrus
Naim have explained why it’s not possible technically, and have said that they would have done it if were possible. Maybe you just don’t believe them, or maybe you are more capable than they are. Whichever, it’s not going to happen.
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: https://wintelguy.com/wanperf.pl
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.
It’s all understandable, but I do wish Naim had some trade-in program. I bought a couple of Qb’s to find out only a couple of months later that they were legacy and wouldn’t receive any new high-res options. At the price it does feel like being given the finger a bit.
Steve,any understanding as to why we have intermittent pauses with many 192/24 streams on Qobuz with the new streamers ie. ND555?
Sorry if this issue has already been addressed
Regarding the intermittent dropouts on a few Qobuz 24/192 albums, the problem has been tracked down and fixed. There has been a delay as during public beta a more nasty issue (random delay between tracks on some networks) was found which has now been debugged fixed and tested by a few customers. We didn’t want to rush out one fix and end up introducing a more fundamental bug to a wider range of customers.
Why did it do it? The streamer uses a data throttle & shaping technology to ensure we don’t use up all the available bandwidth on the users internet connection. Many home networks use free or budget wifi routers and having one device that pulls say 70mbits/sec burst downloading a track from Qobuz into RAM can result in other devices starved of data, or just dropping off the network intermittently on buggy routers.
So, the streamer estimates the bandwidth of the stream, adds a healthy margin on and downloads at that speed. Eg. If the track needs 1.5mbit/sec, we’ll aim to download at 7.5mbit/sec into RAM.
On a few 24/192 tracks the estimator got fooled on how the flac was encoded and the margin was too tight. Eg. The stream needed 6.4mbits/sec on average and the estimator had picked 7mbits. This then exposes the device to data flow fluctuation from the internet as the RAM buffer doesn’t fill up sufficiently.
@Stevesky Just want to say it’s great when you guys take the time to explain certain questions asked!
Hear, Hear! And in a way that even I can understand.
Just confirming does this mean that I can now use Qobuz on my NDX2 and tracks wont drop out? I’m asking as I haven’t received notice of a software update.
I think its due once the other bugs are fixed…
Steve said the patch update hasn’t been released just yet due to everything going on but is in Beta testing currently.
Thanks for the update.