I’m curious about how buffering works on the Naim NSS 333.
Does anyone know roughly how long the NSS 333 keeps audio data in its buffer/cache during playback?
For example:
I start playing a track
Then I replace the network switch while the streamer is idle or stopped
Then I immediately replay the exact same track
Will the NSS 333 fetch the track data again from the network, or could it still be replaying from an internal buffer/cache from the previous playback?
I’m asking because I’m experimenting with different switches/power supplies and trying to better understand whether replaying the same track after changing network hardware is still a valid comparison method on the 333.
Would be interesting to know if anyone has tested this or has technical insight into how Naim’s buffering/cache behaviour works.
If you play a track and then pull out the ethernet cable then you will have the information. When I’ve done so it continues to play the track for some seconds. When I compared ethernet cables I usually pulled out the cable and waited for playback to stop, then put the new one in and pressed play.
There is a thread somewhere where Naim comments on this. I believe the discussion was that buffer size is bigger when using Naim app than say using Connect since Naim have more implementation control then.
The buffer does not retain music data after the music plays. When the network connection is lost, it will continue to play until the buffer is empty. If you go back to the input (eg. UPnP or Qobuz) the app (not the streamer) communicates with the server and tells it what to send to the streamer, so this will fill the buffer again from scratch.
How much buffering is used seems dependent on which interface the music is played through. As far as I know, the players share the same digital board so it should apply to both.
After a track has played in a play queue it briefly shows Next Buffer Level, this is the same behaviour even when it is the same track repeated in the queue, so true buffer not caching.
If you are comparing switches/cables you really need to leave them in the playback chain for some time (I put them in and play tracks on the streamer 24/7 for two weeks), then rotate them to get a true sense of what they deliver. I don’t think rapid switching is worthwhile even with used cables, as what you first hear usually isn’t what you get long term.
I fully agree with you. It was just more out of curiosity, as at the end of such longer period of listening I also would like to do some A/B experiments.
Bear in mind that UPnP is based on HTTP but over UDP.
So caching (which is not the same as buffering but this thread seems to really be talking about caching) can also be controlled by the server. An HTTP-like header Content-Header: no-cache will tell the client the content may not be cached. A cache with a time limit may also be specified in the response header from the server.
This allows the server to set the rules rather than the streamer and on a case by case basis. The reasons for doing this are many but ensuring that the client always gets the latest version is the main one.
As streamers don’t really have storage for this and only volatile memory, they almost certainly are going to treat everything as no-cache and operate with a buffer only on the current queue.
