How does an ND555, bypass the bottleneck of Ethernet?

Come again ?

Your premise is flawed.

They seem quite capable of passing 4k UHD video along their length, and are usually rated at 10 & 100GB. A handful of MB per second won't be a problem. But yes, as Mike-B says, your premise is flawed.

The way Naim do it with new Uniti, and presumably with the new streamers too, is to pull the streaming track into a buffer in the streamer as fast as they can and then take it out of the buffer at whatever rate they need it to play.

This probably means that fancy ethernet cables are just a waste of money for modern Naim equipment (he said provocatively).

best

David

The new streamers are able to accept music faster than it is replayed via a buffer of about 4 minutes of music. So you can actually disconnect from ethernet and they will still play for a few minutes, so in essence there is no bottleneck.

Its the same for the so called 'legacy' streamers,  albeit with smaller buffer.  The streamer takes its data from the buffer, not the cables, or internet.  

However, if you have a poor internet connection, low speed and flaky, with insufficient data accurately received to keep the buffered data ahead of tbe music being played, it will indeed fall down - regardless of cost of the streamer - though the  bigger the buffer the better the chance of success.

For best reliability and assurable quality the answer is streaming locally stored music rather than across the internet. 

Horror of horrors, even the ND555 will only use 100Mb Ethernet rather than Gigabit, which is almost unheard of in even the cheapest consumer electronics these days. Why? Because it’s enough for the amount of data in a music file. 

A few Mb/s should be fine for streaming audio at CD quality. Unless you're on a 56k modem you should be fine. ☺

Yes there is no bottleneck with Ethernet , but there are hardware limitations on the streaming host buffers which have increased in later products.

james n posted:

Come again.

Don't encourage him.

ChrisSU posted:

Horror of horrors, even the ND555 will only use 100Mb Ethernet rather than Gigabit, which is almost unheard of in even the cheapest consumer electronics these days. Why? Because it’s enough for the amount of data in a music file. 

I believe someone mentioned before that although it would seem logical to have gigabit Ethernet the gigabit chipsets are inherently noisier.

i do wonder however why there isn’t enough RAM to buffer a whole album/opera to avoid playback interruptions.  Perhaps circuitry issues again, but 2-4GB should be enough fo most HD works?

Alley Cat posted:

ChrisSU posted:

Horror of horrors, even the ND555 will only use 100Mb Ethernet rather than Gigabit, which is almost unheard of in even the cheapest consumer electronics these days. Why? Because it’s enough for the amount of data in a music file. 

I believe someone mentioned before that although it would seem logical to have gigabit Ethernet the gigabit chipsets are inherently noisier.

i do wonder however why there isn’t enough RAM to buffer a whole album/opera to avoid playback interruptions.  Perhaps circuitry issues again, but 2-4GB should be enough fo most HD works?

Interestingly, Audirvana (which I use as a renderer), apparently loads each track into RAM before playing, so the computer only has to do the rendering while playing.

The new Naim streamers do nof identity a full track and load it, but they buffer 50Mb when each track starts. This is typically enough for a full track at standard 16/44 res. and is considerably more than the old streamers. As for loading up a whole album at a time, I have no idea if this would make sense, but the new streaming card has 512Mb in total, so Naim clearly are not aiming to achieve that. 

I agree it would not make any sense to load a whole album or even an identified whole track.  Buffer size apart its the same as the 'legacy' streamers, the data package arrives & stacks in the buffer & as the buffer vacates space as it feeds the streamer, it gets back filled.  My NDX has 100% buffer with a 24/192 stream & plays for a number of seconds if the ethernet is disconnected,  does it make any difference sonically with a larger buffer,  I doubt it.    The buffer size may well come into play if/when we get WAV files with 32-bits / 384kHz,  time will tell.    

The more music it buffers the better, it is a safeguard against the network jittery / instability, especially the network is wireless, wifi.

Naim uses a patent pending flux compensator engine against the evil of ethernet! Thought that everybody is aware about that....

If Naim used a really large buffer then you could put everything you ever wanted to hear in the buffer and forget about the Internet.

Ah hang on! That is what they do do with the UnitiCore.....

best

David

That's really not how a buffer works. It's strictly temporary memory used for downloading.

What does "temporary" really mean in the life of the Universe? Ten or twenty years seems pretty temporary to me!

best

David

I suppose you've always got a trade of SQ vs usability. Buffering whole tracks allow other processes to be shut down during playback which can be beneficial at the expense of a very slight delay during playback (hardly noticeable but it annoys some !). My own (non Naim amp) has recently had UPnP enabled on its new streaming board and this loads up whole tracks at a time - useful for checking if fancy Ethernet cables make a difference

It'll be interesting how much Network quality affects the ND555 given the greater attention paid to screening and isolation of the streamer section and the memory playback method used.  

Frank Yang posted:

The more music it buffers the better, it is a safeguard against the network jittery / instability, especially the network is wireless, wifi.

A network, despite popular perception, is inherently stable... after all many of the core internetwork protocols we use today were invented to specifically survive nuclear holocoast. Having a larger buffer in our modest streamer devices allows the effects of differeing network latency, that is the round trip timing from end to end to be mitigated. Ironically because our network protocols, and in this case TCP, are so robust, they rely on larger buffers to work effectively when timing latency increases. Now what was happening before in the earlier streamers was the home network was quick, and so the application buffer, that is the buffer above the network stack, was often filling up really quickly, especially on a wired network or descent WLAN, and so the flow control in the TCP state machine kept having to have the breaks put on because the app buffer was full, and abruptly restarted in a rapid stop/start manner. Then on internet streaming where the latency comes into play, the TCP buffer limitations in the streamers were often causing issues with dropouts. The answer was in the next generation streamers was for Naim to increase the network (TCP) buffer and the application buffer, perhaps to more like a regular network attached device, such that the timing characteristics of these different use cases could be more reliably handled by the streamer.

So in short, buffer size aside, cheap Ethernet cables vs Chord Sarum interconnects is null and void as all the data is grabbed into the buffer vs real time data capture in an interconnect?

So ‘time’ is the key variable?

james n posted:

I suppose you've always got a trade of SQ vs usability. Buffering whole tracks allow other processes to be shut down during playback which can be beneficial at the expense of a very slight delay during playback (hardly noticeable but it annoys some !). 

 

Never the slightest delay in playback with Audirvana, even with album-long tracks, or tracks leading straight into one another - but that will be a function of available RAM, and I assume that with tracks leading straight on it must actually at some point load the next one - unless it loads all selected at the time of selection.

Innocent Bystander posted:

james n posted:

I suppose you've always got a trade of SQ vs usability. Buffering whole tracks allow other processes to be shut down during playback which can be beneficial at the expense of a very slight delay during playback (hardly noticeable but it annoys some !). 

 

Never the slightest delay in playback with Audirvana, even with album-long tracks, or tracks leading straight into one another - but that will be a function of available RAM, and I assume that with tracks leading straight on it must actually at some point load the next one - unless it loads all selected at the time of selection.

Yes that's got better over the years. When I ditched Audivarna it was still a bit buggy with memory play usually if the next track was a different bit depth / sampling rate.

I suppose if you have loaded a playlist then intelligent software will start to preload the next track before the others finished to give seamless playback.