But then you need a DAC with separate processing paths for PCM and DSD.
I know and some have just that.
Just merely pointing out, thats all. As it might show it, but what you are listening to isn’t what its showing.
Just I hadn’t seen that information flagged on the display before.
Normally the digital input is just for PCM normally 16/44.1 from a CD transport.
How many NDS users feed the digital input with DoP?
When I had a NDS/ Hotrodded XPS2 for a few months I found that using even a Squeezebox Touch ( with LPS) gave a better sound into the NDS than did the NDS LAN input.
And the U2-Mini/ Elite is now use is light years ahead of the SBT.
1 Like
Considering a different direction for Roon integration.
A Diretta Host → Diretta Target which outputs via USB → UltraDigital convertor → S/PDIF input of NDS
Diretta DDS mode optimizes the general TCPIP data protocol for audio transmission, smoothing out the delivery (RAAT can be seen as very ‘bursty’ which causes spikes in CPU processing), as well as a clean USB output missing out some of the layers of the protocol stack.
Investigation & reading stage at present.
I found an improvement with Primare NP5 mk2 into NDS .. about to trial Eversolo DT8 transport - has better connectivity, substantial build, more expensive .. expectation is that NP5 will move to system 2 to replace ND5XS (mk1) .. into NDAC. But let’s see, nothing taken for granted.
Having spent much time looking at this several years back, the business is down to the client. The server will simply, if using TCP transport, sends the data windows as fast as the client can receive them, and the server can send.
In early Naim streaming architectures the receive window rate was limited in memory size thereby reducing the the amount of data processed and past to the application stack in a period of time. This had the downside that web streaming came liable to latency throughput issues. The early architecture was also liable to create a sonic signature based on the server TCP dynamics. Two distinct TCP flow control were and are still I believe used based on server performance and round trip delay.
In the later architectures Naim decided to change approach and overall it gave a better performance.. that is the receive window size segment memory was increased so greater amount of data could be received before sending any acknowledgement back. This helped avoid over shelming the receive TCP stack. Additionally the the application spooling memory was increased to hold many seconds worth of data. This resulted in controlled bursts of activity with no noticeable sonic signature from network dynamics, and the stack became significantly more robust to Internet round trip delay data flows from streaming CDNs using RTSP.
Now this is using TCP, one could in theory use UDP instead which provided a fire and forget stream from server to client… so the rate could be precisely controlled. This however, is not or rarely used in domestic audio, perhaps because it’s not as robust as TCP. Interestingly I believe RAAT early on used UDP, but then migrated to TCP as it was more robust for consumer home networks and equipment perhaps. UDP is more common in commercial network audio. It’s low latency being a key advantage .
Now USB Audio or more formally UAC, is isochronous, abit like UDP, however it’s a lower level audio specific framing protocol not unlike SPDIF. Its advantage as you suggest is minimum additional processing protocols, its downside it can only be used for physically small limited networks for specific audio data, but in some applications that is all that is required on a point to point basis.
Historically USB interfaces have had a bad press for conducted electrical noise, however with the right engineering design I see no reason why that should always be a limiting factor.
1 Like
Hi,
Interesting, as I research more about the Diretta protocol and the reasons why improved SQ is being reporting is becoming clearer.
Have you looked at Diretta in the DDS mode?
Part of the reasoning is a removal of the ‘burst’ processing of large data packets, present in RAAT, UPnP etc., but I would also imagine with internet based service to overcome the delivery latency given the server is physically and network separate. This bursty data delivery creates spikes in the required processing. And as everyone with a ND555 has experienced, spikes in processing has a negative effect on the overall SQ (the background of firmwaregate)
The protocol over the actual Diretta DDS link from Host → Target is then more of a UDP like, Precision-Time-Protocol (PTP) before this is output over a USB connection.
Certainly elements of the protocol stack/inter-stack communications are then not needed.
There is also benefit of operating the Dirreta link between Host & Target at 100Mbps or even 10Mbps.
While this is interesting, it also makes me think that there may be an advantage of the smaller buffer in Naim’s earlier streamer boards. This obviously was a disadvantage if you wanted to connect the network player directly to the internet and stream content over the internet from an internet-based service such as Tidal or Qobuz. This limitation is easily overcome with off-board servers to front and marshall the interaction with the internet and the internet-based service.
However, if the smaller buffer was in fact limiting the size of data transmission, by reducing the amount that could be processed, then the stream from a UPnP server or UPnP Bridge is going to less ‘bursty’ and much more of a controlled steady flow. Steady data flow consuming less processing drawing less power, less noise from both the power supply and the processing of the data stream.
Maybe the smaller buffer which limits the overall level of data processing at any time, as long, as the service providing the stream is physically local (or on the same local network) and can deliver the next elememt of the data stream before the buffer is emptied) presents more of a continous data stream to the network player, with less noise involved in its processing.
The gen2 streamers seem far less susceptible to noise (other than background noise introduced by FW3.10, before anyone mentions that!).
On our 272 you could hear a difference between FLAC and WAV served from Asset. On our NDX2 (transport only) we could hear no audible difference.
FLAC is designed to put a very light load on the decompressing device (streamer).
It seems the gen2 devices, with bigger buffers/cache, simply have much more processing power such that any noticeable effects of network packet timing or codecs have been mitigated.
When playing from our NAS the NDX2 buffers a large duration of audio, so there’s really not a lot of network traffic happening during playback. TIDAL also buffers loads.
1 Like
Or so you think!
Perhaps the lack of perception between FLAC and WAV is the fact that a level of noise is always present, resulting from the processing of the stream, rather than the processing of the format.
Just saying!
I only present my NDS with either WAV or DoP for DSD
The larger buffer just mean that there is a burst of network activity delivering the packet(s) to complete the buffer fill, which is then processed the buffer starts to empty (first in, first out), at some point, signal will be provided to the server for more data to fill the buffer again. This is the next burst of network activity and data delivery processing.
The premise of Diretta is to smooth out these spikes or bursts of data delivery, and so reduce the noise resulting from the network activity and data processing
A smaller buffer, however, containing less data is going to be ‘topped up’ more often and because the extent of the data delivered is smaller, the time taken for the buffer to be filled shorter - effectively the processing is almost continuous with no real spikes or periods between data delivery.
1 Like
I am not familiar with that, no, I will take a look.
Regarding the cpu bursting… and memory writing. This was an issue in terms of audibility in Naim’s first gen streamers products … that they effectively mitigated to the point of irrelevance with the later streamer products which specifically used an isolated using LVDS (designed for such use cases) self contained transport module.the fact we don’t hear a warbling pulsating change in SQ every few seconds demonstrates this works… or at least I am not aware it being observed.
The SQ issues with the firmware were with the main ARM CPU execution timing cycle in the Naim streamer. I know in past firmwares Naim adjusted this timing cycle to minimise and/or execution noise affecting ground planes, and sample replay clocks.
1 Like
Interesting to hear your results, the Primare in my system is very good and every review I read talks about it performing way above its value. I found the iFI Xpower PS improved it significantly too, for not much money.
The issue I have been having with it is around my Android device dropping the app after a few tracks sometimes and being generally a bit clunky. It is irritating but not fatal, and the iPad version is OK. The NP5 did have a flaky few days after a recent update but has settled again now!
I might look at a Lumin U2 Mini if I was going to try anything else but I am in no hurry. I just like the combination of NP5 and NDS in my system.
Bruce
1 Like
Well we have found the real wins come from separating streamer and DAC into isolated boxes.
What format our transport receives makes no audible difference.
Still toying with idea of an NDS, as DAC only.
1 Like
A good BNC is mandatory. Vs the Chord Shawline, my entry level Snake River is quicker, snappier, and gives the Naim prat. I would not take a cheap Belden to really see what a good transport can give with the Nds dac.
1 Like
The problem with android is there are so many different makes of phones using it. They don’t all work in the same way and changes to phone software could mean any apps could start having problems.
My NP5 was working perfectly with my Honor mobile phone until a few months ago. There was a major upgrade to the operating system (or something), which has resulted in a pretty annoying glitch. If I’m playing an album and hit the back button, I don’t get the previous page, I go right back to the start and have to turn the NP5 on again.
It’s not a major problem as I have an older phone and tablet that still work perfectly.
It seems that Primare aim to provide a neutral sound with all their equipment. Other equipment might not be so neutral which people may prefer, but if you have a neutral streaming bridge you can tweak the sound by choosing different Ethernet or spdif cables.
1 Like
Not sure that’s all correct…
For the 10/100 vs Gigabit, the signalling for the former uses just 2 of the 4 twisted pairs in the cable, one dedicated for send and one for receive. Gigabit uses completely different signalling over all 4 pairs and achieves the send and receive using clever signalling so it can get the required bandwidth. So I guess it’s possible in ‘noisy’ systems that 100Mbps may introduce less unwanted noise into the system. (Noise is not data loss…)
As for buffering, the newer boards with more RAM buffer the entire track very quickly if it’s less than 50MB, and then network activity pretty much stops dead. This is the same whether it comes from a local uPnP source, or from Qobuz over the internet as long as you’re using the Naim app. If you use Qobuz Connect, then you get a different server pushed stream that is more constant, and here Naim only buffer around 6 seconds worth. So if you have a system that is noise sensitive, Qobuz/Tidal connect keeps the streaming board more active.
Also of interest (I think) is that it seems the streamer board is only active in filling the RAM buffer, and what goes in there is the unchanged format you are streaming. The ARM processor does not appear to be involved in uncompressing the format streamed. This appears to be done by the SHARC DSP which also oversamples and filters.
The other thing with newer players is the format and bit rate. If you use higher resolution formats that have a track size greater than 50MB, the buffer will be filled quickly, but then can only be topped up at the same rate the DSP empties it until what’s left of the track fits into 50MB, at which point again, network activity stops.
I don’t know what the RAM buffer size of the older players is, but it looks to be significantly less than 50MB as my ND5 XS appears to draw data from the NAS for pretty much the entire length of the track, so the network is always active which is a stark contrast to the ND5 XS2.
Perhaps future Naim streamers will have even bigger buffers to cope with more 24-bit 192kHz data.
It does beg the question though, is there an ‘ideal’ track file size for optimum network playback, i.e. if it fits in 50MB (compressed) do you suffer less from network noise through the ARM as it’s far less active in this scenario…
Exactly my point - there is no burst of network traffic and data processing as more data is received into the larger buffer.
Is a continous stream of data exchange and processing, as the Diretta protocol has found, providing for a better SQ for the DAC?
Also on the 10Mbps or 100Mbps in the Diretta DDS ‘Super Purist’ or ‘Purist’ mode, this is not standard Ethernet procotol, but a derivation of a TCP/IP stack but implemented as a PTP-based dedicated communication procotol between the Diretta Host and Target as a private point-to-point connection (i.e. not on the LAN).
It will be standard physical ethernet, just not using the IP stack, IP can run over many different physical mediums. So the physical signalling differences will be unchanged. Else you’d need bespoke ethernet cards, which it does not have as you can run it on Windows etc.
Not sure I understand? If the newer players fill the buffer in a couple of seconds (appears to happen), then the streaming card is inactive for nearly all the track, so I would have thought that you can’t get less ‘noise’ than that?
Edit: I’d also add that the DAC is not fed by the streaming card. It’s fed by the SHARC which pulls data from the RAM buffer and re-clocks it there. The SHARC is doing the heavy lifting on processing the delivered data.
From the Diretta site:
The L1 to L7 refer to the OSI Network Layer Model, and shows they do actually use IPv6 for initial session establish/authentication and then drop down to L3 for end to end data between Diretta systems. So they don’t touch the physical cabling (L1) or raw ethernet frames (L2) as touching either of those would stop initial use of IPv6 at L3.
A Diretta host feeding an NDS over BNC/SPDIF bypasses the streaming card in the NDS, and if you have a remote then you don’t even need an NDS to be connected to any network, so only the SHARC is involved. Personally I would have thought for the NDS, the quality of the clock in the device feeding the SPDIF connection would be the important part as this gives the NDS less work to do on jitter correction. In this config, short of a WiFi router being sited atop the NDS, the amount of network noise/processing shouldn’t matter.
Most of the implementations I have seen of the Diretta ‘Host’ are Linux based - the Roon positings talk about using AudioLinux for this.
Most of the DACs being used as with a USB based input.
This is why I am only looking, reading and investigating this, and not committed to implementation. With output only being USB, use with an NDS would involve conversation to S/PDIF, with all the problems of that protocol.
I already have a USB → S/PDIF convertor (a XMOS based Sonore UltraDigital) which I use off the USB output from the Sonore UltraRendu when in its NAA mode with Roon. Normally I use the UltraRendu to run the SonoreUPnP Bridge for Roon.
But it performs about the same as the UPnP feed - a little colder & darker.
My thoughts were could I get a better USB based feed to it, and this would improve over either the RAAT or UPnP based protocols.
I have to say I’m not entirely sure what problem Diretta solves, it seems like a lot of work at low network levels for I’m not sure what gain…