NDX 2 display

Dear All,
I do apologize for a silly question. Since today I am a happy owner of NDX2 after 5,5 years of usage of NDX. Is it possible to come up with the “buffer level” information on a display as it was possible in NDX?

Kind regards

No, the buffer level is not displayed on the new streamers. I guess Naim are hoping that you won’t need to check it, as the buffer is considerably larger and hopefully will not be prone to emptying as it did on the old streamers.

Thank you.

Indeed, a different method of ‘buffering’ is now used on the current streamers … essentially the track is now loaded into memory and played from memory, although play out starts almost immediately.
The network connection is now only used with regard to media transfer whilst a track is being loaded into memory on play out commencement. On longer tracks, especially hidef, the memory is topped up whilst the track plays out. As Chris says there is no way via the display to see current memory usage.

To help demonstrate the above, I have watched my network transfer from my Nas to the ND5xs2. You clearly see a blip in activity as the Nas supplies the streamer with data. There is then no activity until just before the next track us loaded from the Nas. Shown by another blip. The idea that the Nas is constantly supplying data is outdated. I guess the same is true from Spotify/ Tidal et al.

That’s only true if you are playing relatively short tracks at 16/44 or below. The buffer is 50MB, so a long track, or any hires track, will fill the buffer initially, then continue to top it up as the track plays out.
A regular album of fairly short tracks at CD quality would look like this:

So there is very little data being transferred arter the initial burst. Play a longer track, or one at higher res, and it looks a bit different, with data still flowing for a while until the whole track is loaded:

Try playing classical music where the tracks are longer, in DSD, and you would see even an more protracted flow of data. Still, that’s better than the old generation streamers, where the much smaller buffer is almost constantly being topped up after the much smaller initial burst:

Simon will no doubt tell me off for oversimplifying things, but you get my drift? Still, all that matters is that it works.

1 Like

That’s great interesting. Most of my tracks are 44/16 Alac files. Surprised the buffer is only 50mb. Which of course explains why it has to be topped up from the Nas. ( Looks like the plot from a Synology?)

Yes, it’s the Synology resouce monitor, with no other significant activity on my network it gives you the general idea of what’s going on.
50 MB might not sound like much, but it’s a lot more than the old streamers had, so I guess Naim figure it’s enough - given that they were acutely aware of the problems caused by the small buffer when lossless web streaming was introduced.

Not oversimplifying at all, that’s a good illustration.

Actually there is a variant more noticeable on the old streamers but still occurs on the new last time I looked, is that the TCP windowing flow control switches between two different modes of operation depending on throughput and latency… this comes more into play for streaming from the cloud or streaming over wifi… so your bottom trace can appear on your new streamers where the slower flow windowing method is used.

So how does this pan out for the ethernet cable crowd?

1 Like

exactly when one is talking about how the cable affects like quality of signal and jitter etc… but of course an ethernet cable is a source of noise and the effects of this noise coupling to our system is i suggest what many hear… and down at the physical layer there is actually framing sync modulations on the cable irrespective of any data passing through the cable.

Ok, but on the basis the song is buffered, then the logical conclusion is to use wifi. which I guess goes back to recent posts you have made.

No need to spend out on those ethernet cables after all!

yep - indeed - there are pros and cons with both

1 Like


On the newer platform (Atom and derivs) we introduced the concept of large buffers and network bandwidth shaping. The main goals of these were to give robustness to services like Tidal and reduce network load under main playback.

The sound implications though are not as clear cut as simply transferring data though:

  • ethernet can inject noise into the hifi via grounds and radiated noise on the data lines. Experiments with various ethernet cable constructions can potentially help matters here + higher quality network switches. Also cheap switch mode psu’s plugged into same outlet as the hifi can take the edge off the sound.

  • wifi is a variable power system and the more rf power it uses to talk to the wifi router, the more radiates into the product and it’s not an ideal situation. On products with internal ‘heat sink slot’ antennas we pay a lot of attention on ensuring the field mainly radiates outwards.

Remember, even when its playing from internal ram, there is always lots of other traffic going on. It’s not like it’s electrically quiet on either interface.

Regarding services like Spotify, Airplay2, Chromecast and Roon, do their own buffering schemes but typically buffer far less than the 50MB that Naim allocate for Qobuz, Tidal, UPnP and Internet Radio.


Steve Harris
Software Director
Naim Audio


wifi is a variable power system and the more rf power it uses to talk to the wifi router, the more radiates into the product and it’s not an ideal situation.

Does a more robust wifi network use the less power and therefore radiate less into the product? Or is the power related to the amount of data being transferred so the higher the resolution, the more power used and the noisier it becomes?

My preferred goal is to optimise wifi rather than run cables all over the house and introduce further variables by doing so…

I’d start off with a site survey and plan where you want to locate your access points relative to the client devices.
These days you have a lot of options as to how you install access points and how many you install.
A good option if you’re prepared to do some cabling is to have wired access points that are powered using Power over Ethernet (PoE). Ideally the higher up they are installed the better to reduce interference with objects in the room like furniture, you can mount them on the ceiling for example.
If running Ethernet cables to the access points is prohibitive, you can still power them from the mains locally and use an access point with a dedicated backhaul radio and create a wireless mesh network.
Ideally have at least one primary Wi-Fi access point that is hard wired to your main Internet router and then you can add additional satellite access points at further away locations relative to the wired access point.
As an example, I have a house split across 3 floors with an access point on each floor.
The one in the basement is wired over Ethernet to the main Internet router, the satellites on the first and second floor are using a dedicated wireless backhaul radio to create a whole home mesh.
The satellite on the first floor is in the same room as my NDX2 and is situated on top of a tall coat cupboard and has line of sight to the NDX2.
All 3 of them are freestanding but placed high up in the room they are located in.

Public Internet -> Service Provider Coaxial cable -> Cable Modem -> Ethernet cable -> Router -> Ethernet cable -> Switch -> Ethernet cable -> Wired AP —> Wi-Fi Satellite —> Wi-Fi Satellite

Thanks Mr.M

I currently have a mesh set up. Primary access point (wired to router) and 1 more access point at the other end of the 1st floor. These two also give me pretty good coverage in the basement garage and out to the garden. Then 1 access point on each of the 2nd and 3rd floors, in the central stairwell. The house has full coverage, mesh connection is solid, internet speed is around 310 up / 290 down and speed test with my phone (speetdtest.net) at the HiFi location on the 3rd floor is +75Mbps.

Public Internet -> Service Provider Fibre -> Fibre Modem -> Ethernet cable -> Router/Primary Access Point -> WiFi -> Access Point 1-> WiFi -> AccessPoint 2 -> WiFi -> AccessPoint 3 -> Future Streamer ?

I don’t have ethernet cable options from my access points (other than the primary/router to modem) but the WiFi appears robust and I would prefer to use it when I eventually introduce streaming. @Stevesky comments made me wonder if this is enough to assure optimum sound quality by allowing a wifi enabled streamer to consume less power or if the power consumption he referred to is more related to the data stream than the wifi strength.

I imagine Steve’s comments refer to the signal strength between the Access Point and your ND streamer.
As you move your client device further away from the AP it connects through and increase the physical obstacles between them the signal will degrade and the amount of data that can be transmitted and received will reduce accordingly.
The ND products are designed as Steve highlights with a generous 50MB buffer, sufficient to accommodate most scenarios.
There are a number of applications you can use on a PC or mobile device to give you more information about the characteristics of your Wi-Fi network relative to the device running the application.
Ideally locate the AP high up in the room and minimise the amount of physical obstacles between it and the ND streamer.

Sounds like I could be well positioned for good WiFi performance then. The 3rd floor access point is about 4m away and in direct line of sight to where a streamer would be sited.

I wasn’t too concerned about the strength of signal and reliance on the buffer as I know I have a strong signal, I just wasn’t sure what might cause the fluctuating power consumption and resulting noise. If that’s mainly due to the device chasing a weak signal I should be in good shape.

All I need now is to identify what my future streaming set up might look like but it’s great to know I won’t have to worry too much about networks and switches etc.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.