Inside NDS

There are many work arounds to the NDS and streaming. I could use one happily in my system straight off (Audirvāna) and I have liked the nDAC in the past. I didn’t for two reasons.

  • I’ve never thought relying on a third party streaming board was ideal….
  • I didn’t really want to go to a two or even three box source.

So I looked at alternatives and went the Linn route. I think Naim excel in amplification, streamers not so much.

Actually I believe the BridgeCo board was developed for internal UPnP streaming and internet lossy Ogg streams from Spotify, which was the main streaming service at the time . .. but this excluded lossless FLAC internet streams which is where some of the later challenges came in,

The main issue for Naim was the processing speed limitations of the BridgeCo network stack which meant there were challenges with TCP for a higher throughput, such 44.1/16 FLAC when latency was slightly increased. Internet latency is typically higher than local subnet streaming as traffic has to be routed on the Internet, where as not for local upnp. However this was a reason with the BridgeCo modules why Ethernet was recommended over WiFi for local streaming… nowadays with the right decoupling WiFi or Ethernet is largely irrelevant.

Naim did work to optimise the efficiency of the BridgeCo software driving the hardware to mixed results when Tidal came along with lossless FLAC.

The initial streamer BridgeCo boards for the NDX were limited to smaller playlists and 96/24. A free dealer swap out for a higher spec BridgeCo module was early on available that provided 192/24 and larger playlist sizes. ISTR that the subsequent NDS launched only with these later BrideCo modules.

BridgeCo was disbanded around 2012 when it was acquired by SMSC and then finally Microchip Technology so became an enforced dead end, so a new partner was required by Naim.

From what I recall of the timelines involved, the first Internet services added was Spotify, at a lossy ‘below CD quality’ and this streamed ok but sounded poor. Next was Tidal with CD quality loss, which was acceptable. However this streamed fine for some but was problematic for others. This is where the buffer issue in the BridgeCo board was discovered. At the same Tidal was down the ‘Tidal Master’ path encoding HiRes content in MQA, which Naim had decided not to embrace.

I’m not sure there was the opportunity to work with BridgeCo board provider again, plus a number of other standards had also moved on - Bluetooth, WiFi, AirPlay and although completely irrelevant for HiEnd use, important as tick box items for mass market consumer use. Same with the colour screen, mono green screen was viewed as old-fashioned. Completely useless across the room, but looks more modern against the latest offerings.

So a new streaming architecture in a new line, as well as a price hike for new flagship to cover manufacturing costs, knowing that many existing customers would just upgrade regardless.

This bought in the Streaming Unlimited board, which solved all the network connectivity and was upto date with Bluetooth, WiFi, AirPlay2, RoonReady, Over-the-Air updates and most importantly all the required compliance work for Naim to be able to market the new range with all latest technology items, for the mass market to view it as upto date, in the now very competitive streamer space.

But who was to know that the Streaming Unlimited board came with hidden firmware issues that would kill the performance and the sound especially in the flagship, a problem still being dealt with today in the latest Beta firmware, after an entire year or so.

Tidal has subsequently changed direction with Masters for Max, as Qobuz launched their HiRes FLAC service.

Another solution to retrofit is an off-board server for the WAN connection within the user’s LAN approach, or extend the capabilities of the UnitiCore server to provide this. But this would not be straightforward and an additional cost for the user, increased product & technical support as would be more complex for users to setup.

Networking in the mass market space has to be a simple Plug n’ Play operation - additional networking connections & cables, requiring switches, just increases complexity.

Any user willing & able to go this route was more likely to undertaken it with 3rd party products anyway, hence the solutions available today.

All of these work well but the consumer user has to do a little more, configure more than one networking product to get the desired outcome, so not for everyone.

Analogue is the same, if you are prepared to spend time matching components, setting them up, a better result can be obtained over a ‘product in a box’ approach.

1 Like

But used with Wired Ethernet and with a ‘localized’ UPnP stream there is no performance issue or problem with the BridgeCo board or its networking stack.

The BridgeCo board was optimized by Naim for local streaming and offers excellent performance when used appropriately.

The Ethernet vs WiFi is somewhat irrelevant as most HiFi manufacturers recommend wired Ethernet over a WiFi connection anyway, some HiEnd providers don’t even include WiFi capabilities in their products.

Quote

“But who was to know that the Streaming Unlimited board came with hidden firmware issues that would kill the performance and the sound especially in the flagship, a problem still being dealt with today in the latest Beta firmware, after an entire year or so.”

The answer is Streaming Unlimited, or whatever they are called. A so called partner that was effectively spying on its partner, taking processor time and creating distortion/artefacts etc leading to Firmwaregate.

1 Like

Indeed as I said - switched subnet traffic which is what UPnP utilises has a lower latency, therefore the bandwidth, latency, window memory ratio equation in the network stack can operate such that latency can increase but bandwidth reduced, or higher bandwidth but lower latency. There was no general issue with Spotify using Ogg either.

The challenge came when it was both higher bandwidth and higher latency - because the network segment window memory was fixed in the BridgeCo boards - so effort was spent by Naim (and possibly BridgeCo - I only know about the Naim involvement as I was helping Naim on this at the time by wiresharking various candidate builds) in optimising the network code so as to keep the segment confirmations running as quickly as possible.

The BridgeCo board was designed for internet and local network use (for example it has the hardware and code to negotiate session encryption which is not used for local streaming) - but only for lower bandwidth internet use - such as used WebRadio and Spotify lossy. UPnP AV is an old protocol now and such has no security.

Modern solutions tend to be ambivalent on ethernet and wifi, but it’s true in consumer space there are more variables with wifi - much of this preference for ethernet stemmed from early implementations to use ethernet only and wireless added noise into streamers because of lacking implementations - this came a folk lore for a while. A decade later modern wifi can provide benefits over ethernet not least through network noise reduction and common mode noise. I have decoupled links and there is NO difference at all between wifi and Ethernet and I see this increasingly now on this forum too… but for me the final layer 2 segment is ethernet to my streamer… just for convenience… and unfortunately still not entirely convinced of the NDX2 wifi implementation. The ideal would be direct fibre ethernet connections. Ideal for low network noise and no common mode noise… one of the reasons Naim shied away from fibre as they felt it was too complicated and inacceable for the average Naim customer so I was advised several years ago. Fibre and wifi might be more attractive at some point going forward, and cut out the challenges associated with wired ethernet. Modulating 2.5 or 5 volts at around 30MHz into 100 ohms or so into a non ideal reflective transmission line can creates some real low level noise mitigation challenges when using ethernet. Wifi has its own challenges - but the transmission is better controlled into the antenna in terms of reducing reflections that can add noise into ground planes in the host and the noise power is lower and there is no HF common mode.
Wifi typically has a power density of 20 to 100 mW depending on distance to AP and other factors where as ethernet has around 110 to 300 mW power density per port. Now there are specialist driver chipsets produced by TI and others to mitigate the issues with twisted pair Ethernet noise for ultra low noise environments - but as far as I am aware those are not generally used in consumer hifi products.

But the original preference for Ethernet was both for SQ and latency/reliability reasons back in the day - especially for higher bandwidths where drop outs could occur sometimes irrespective of the wifi throughput.

2 Likes

But again, if the BridgeCo board is used with what is presented as a ‘localized’ UPnP stream (irrespective of where the stream originates whether from local files or internet-based services from Tidal, Qobuz, lossless FLAC internet Radio etc.) it works perfectly without issues.

Which can report and relate to, based on actual current usage with my NDS and the ‘localised’ UPnP feed coming from a UPnP Bridge from a Roon system. The Roon system marshalls both locally stored content (in all formats PCM, MQA, DSD etc.) and ALL content from internet based music & Radio services WITHOUT issue.
I am not talking hypothetically or based on experiences or measurements made years ago, but an actual system configuration presently owned and used by me on a day-to-day basis.

1 Like

The same will be for Audirvāna as with Roon. A very sensible way of using an NDS.

Interesting ,what streaming board did Linn use ?
My Linn Majik DS from -2008 stream Flac internet radio without problems into Naim NDS as Dac.


it does as I have said a few times now - and one needs to use a proxy server or a network bridge of some sort. Here the TCP responses are much quicker when come from a proxy within the same network, as the peer to ND X/S peer is within the same subnet. But as I keep saying this is ideal for peer to peer within a subnet and therefore is ideal for higher bandwidths with the BridgeCo as TCP acknowledges occurs quicker.

I used to run such a setup for my NDX for a few years which ran reasonably well (I think I landed in the end on BubbleSoft) until I replaced it with my NDX2 with the alternate Streaming Module - which meant this all became irrelevant.

Are you not using SPDIF for this however? Which bypasses the network streaming module in the NDS/NDX

This is controlled by Analog Devices SHARC processor and local processor on the main NDS board.

1 Like

Yes SPDIF to the NDS(only as a Dac)but the old -2008 Linn Streamer as
Flac internet radio streamer.

Plus adopting this ‘off-board’ approach for internet based activity, plus Roon support will reduce the level of processing required ‘on-board’ for the NDS.

As has clearly been seen with the issues experienced with the Stream Unlimited board, with hidden firmware introducing additional CPU load and processing, significantly impacting the performance levels, that reducing ‘on board’ load and processing is in fact a much better and more consistent approach for the handling of these services.

1 Like

I think the question was ‘What streaming board’ does Linn use, as their earlier products circa 2008 are able to marshal lossless FLAC radio stations.

But the more interesting question is whether the Linn Majik DS acting as the front-end to an NDS with S/PDIF based digital fee sounds better than using the DAC in the Linn Majik DS?
Does the DAC in the NDS even with an external S/PDIF input outperform the Linn version from the same era?

1 Like

I see, I have no idea.

1 Like

Thank you,yes that was what I meant.
I think that the NDS as a Dac improves the sound
very much over the internal Dac in the Linn Majik DS.

I take it a step further and decouple my streamer from my DAC via SPDIF (I have used USB as well for non Naim). I didn’t experience the significant firmware sonic issues that some experienced - thought I could hear subtle changes.
But separating DAC from streamer largely isolates all the faffing about with audiophile type network products as they make really no difference now in my setup (or at best what you might notice with the change of air pressure or temperature with your speakers - which is marginal) - These audiophile network products in my opinion are ridiculously over priced anyway for what they actually do… but hey they do tend to be put into nice cases…

3 Likes

Not the point I was getting at.

The firmware issues experienced with the Streamer Unlimited, where some hidden code increased the CPU load and processing on the ‘on-board’ processing which destoyed the SQ, as experienced by many ND555 users as listed on that forum thread and referred to as ‘Firmwaregate’.

So having all the processing required for the internet-based streaming services processed ‘off-board’ minimizing the ‘on-board’ process to just handling a UPnP stream is actually a better approach.
So although the BridgeCo board does have a limitation preventing it from handling these services and streams, the work arounds need to address it, actually provides a better solution, with less opportunity for noise being introduced into the steamer.

Less noise, better SQ (as Naim has always told us).

1 Like

Indeed - and as I say I take it a stage further and remove or network protocol processing off board from the DAC so I have good EM and electrical noise decompiling. Here I am simply sending SPDIF framing into my DAC. And if I used a NDS / ND555 / NDX /NDX2 etc by inputing from a streamer providing digital audio using SPDIF I am completing isolating the streaming module.

But yes you choose where you want to put that line…
The key thing is you choose that demarcation point and if you get it right for you and your setup then this all becomes moot and you cease concerning yourself over it.

1 Like

I remember trying this too, using BubbleUPnP Server on a Synology NAS. It worked well as a way to get Qobuz on a 1st gen NDX, as well as improved stability with Tidal. It also sounded better than native Tidal.

When I moved to NDX2 (also with Chord Dave) I no longer needed Bubble for Qobuz, but out of curiosity I tried it just to see if it still worked. It did, and it gave a marked improvement in sound quality of both Qobuz and locally streamed music. Try it - you might like it!

3 Likes