Article: dCS Network Bridge Review

[jay]

7 hours ago, maxijazz said:

Nowhere to be found in the quote an opinion, that sound from Roon is inferior. 

Sorry, I felt it was implied in the question...in particular the sentence referencing "other reviewers."  I do see the follow-on comments regarding the Aries...thanks to shinyc for clarifying.

 

Regardless, if HQPlayer is not compatible, I suspect many would argue that with certain DACs, you're potentially losing out on some SQ when using Roon based on a lot of the findings here, including my own.  Others may wholly disagree.

 

All of that not withstanding, hopefully I'll be able to demo a dCS Network Bridge myself.  I'm merely hoping someone had already done the comparisons and could comment.

[shinyc]

Stereophile reviewed dcs NB a while ago and there was a mention that SQ from roon is less than from its own player.  Other members on CA do feel substantial improvement from employing dcs NB box (or Aries G2 box). I, too, am curious if dcs NB would produce higher jump than, say, hqplayer/AO/jplay/fidelizer/iso-regen/....... I guess I will ask for a demo unit and find out myself. 

 

[k-man]

Since Network Bridge accepts data from UPnP, HQPlayer Embedded should be compatible as a UPnP renderer.

[blaven]

I am finally intrigued enough to consider this in addition to my Aurender but appreciate help.

 

I presently run Aurender S10 (USB) --> Berkeley alpha USB (AES out) -- Meitner MA1

 

Since I am already using the AES off the Alpha USB to the Meitner, should I then use SPDIF from DCS Network Bridge to Meitner MA-1.  I am concerned about jitter issues with SPDIF (less of a concern with DCS clocking?)and the quality of a SPDIF input o the Meitner or other DACs as I have only used USB and AES previously.

 

I figured I'd post this here as I am guessing others that would consider adding this would have similar possible issues

 

Thanks!

 

 

[The Computer Audiophile]

24 minutes ago, blaven said:

I am finally intrigued enough to consider this in addition to my Aurender but appreciate help.

 

I presently run Aurender S10 (USB) --> Berkeley alpha USB (AES out) -- Meitner MA1

 

Since I am already using the AES off the Alpha USB to the Meitner, should I then use SPDIF from DCS Network Bridge to Meitner MA-1.  I am concerned about jitter issues with SPDIF (less of a concern with DCS clocking?)and the quality of a SPDIF input o the Meitner or other DACs as I have only used USB and AES previously.

 

I figured I'd post this here as I am guessing others that would consider adding this would have similar possible issues

 

Thanks!

 

 

Hi Blaven - It will likely be a trial and error thing to get the best sound quality. I’d have both an AES and S/PDIF cable and try each interface on each device. There are variables such as which one is best on the D to D converter and D to A converter. 

 

Part of the fun is spending time listening to every configuration possible and deciding for yourself. 

 

If the MA1 has BNC that’s a plus as well. 

[blaven]

Thanks.   The MA1 does have a BNC. I would definitely try all the options- agree wholeheartedly that is the fun. 

 

I would ideally have a situation though where both the Aurender and the DCS network bridge could be connected to the DAC at the same time to avoid the hassle of repetitively unplugging the ARS (likely best off both DCS and Alpha USB) each time I listen to one or the other path. 

 

Given the ideal  set up of having both connected to the DAC at the same time, I’m guessing it likely would be SPDIF off the Bridge.  

 

Perhaps the DCS re-clocking helps with jitter issues known to SPDIF?

[luisma]

23 hours ago, blaven said:

Thanks.   The MA1 does have a BNC. I would definitely try all the options- agree wholeheartedly that is the fun. 

 

I would ideally have a situation though where both the Aurender and the DCS network bridge could be connected to the DAC at the same time to avoid the hassle of repetitively unplugging the ARS (likely best off both DCS and Alpha USB) each time I listen to one or the other path. 

 

Given the ideal  set up of having both connected to the DAC at the same time, I’m guessing it likely would be SPDIF off the Bridge.  

 

Perhaps the DCS re-clocking helps with jitter issues known to SPDIF?

so it does reclocking internally, does it shares clock sync with the DAC over AES? any plans to go beyond DSD128 to DSD512?

[Vinh]

Very good review. This is a very expensive toy.  Could someone recommend AES output gear for 1/2 or 1/3 of the price ---for an Yggy owner ?

[firedog]

44 minutes ago, Vinh said:

Very good review. This is a very expensive toy.  Could someone recommend AES output gear for 1/2 or 1/3 of the price ---for an Yggy owner ?

Bricasti M5. A little over half the price. I am very happy with mine.

[JBNY]

Thanks for the review. It is too bad they still don't support a USB DAC connection, I had to remove this from my list of equipment I was looking at a while ago. I'm glad I didn't make a purchase as it seems they still don't have USB working for a DAC connection.  

[stevebythebay]

5 hours ago, Vinh said:

Very good review. This is a very expensive toy.  Could someone recommend AES output gear for 1/2 or 1/3 of the price ---for an Yggy owner ?

Been using an Audio Alchemy DMP-1 with the Yggdrasil for quite some time.  Works nicely.  Not sure where you might find one these days.  Got mine for just under $1k when Audio Adviser was offering them.  Might want to contact ELAC as they now own the line of Audio Alchemy products.

[Vinh]

Thanks, very good suggestions.

[AMP]

On 6/15/2018 at 11:52 AM, rikhav said:

Any idea if the data got from the ethernet input is reclocked

 

Reclocking is one of those words that is so overused in marketing fluff that it's tough to determine what it actually means. In fact, it's a made-up word that has no meaning at all

 

Network data (audio or otherwise) is transmitted asynchronously which by definition means that it is not dependent on any clocking reference that corresponds to any other clock. "Clocking" in the digital audio sense is only an applicable term when we're talking about synchronous transfer mechanisms like AES, SPDIF, SDIF, TOS, I2S, etc. While the physical layer of Ethernet relies on an oscillator to time pulses on the wire, that clock has no relation whatsoever to the clock in the DAC.

 

Furthermore, all network streaming devices (really all network devices) make use of memory buffers to temporarily hold the data packets and either re-packetize them for transfer back over the network or hold them for reassembly. In the case of a streaming device there's a memory buffer that's filled to a safe level from the network and metered out according to the audio clock rate. In the case of the network bridge the clock reference used to roll data out of that buffer is either one of the internal oscillators or an external word clock.

 

The "clock" in the audio sense doesn't come into play until the data is moved out of the network buffer an is prepared for transmission to the DAC. At that point it becomes synchronous, is processed in real-time, and the clock becomes incredibly important.

 

The vast majority of the "reclockers" on the market (network or otherwise) are simple store-and-forward buffers. Nothing magic about them and, frankly, they're likely to do more harm than good. Remember, you can never make bit-perfect data more perfect, but you can sure as hell screw it up!

[One and a half]

On 6/21/2018 at 2:18 AM, stevebythebay said:

Been using an Audio Alchemy DMP-1 with the Yggdrasil for quite some time.  Works nicely.  Not sure where you might find one these days.  Got mine for just under $1k when Audio Adviser was offering them.  Might want to contact ELAC as they now own the line of Audio Alchemy products.

Had a search the other day and Elac for sure under their banner, but very little in the way of online dealers that list the alchemy.

 If anyone can share a recent experience to find a supplier would be keen to follow through.

 

Did the DSD click on track change resolve with the dcs network bridge?

[rikhav]

5 hours ago, AMP said:

 

Reclocking is one of those words that is so overused in marketing fluff that it's tough to determine what it actually means. In fact, it's a made-up word that has no meaning at all

 

Network data (audio or otherwise) is transmitted asynchronously which by definition means that it is not dependent on any clocking reference that corresponds to any other clock. "Clocking" in the digital audio sense is only an applicable term when we're talking about synchronous transfer mechanisms like AES, SPDIF, SDIF, TOS, I2S, etc. While the physical layer of Ethernet relies on an oscillator to time pulses on the wire, that clock has no relation whatsoever to the clock in the DAC.

 

Furthermore, all network streaming devices (really all network devices) make use of memory buffers to temporarily hold the data packets and either re-packetize them for transfer back over the network or hold them for reassembly. In the case of a streaming device there's a memory buffer that's filled to a safe level from the network and metered out according to the audio clock rate. In the case of the network bridge the clock reference used to roll data out of that buffer is either one of the internal oscillators or an external word clock.

 

The "clock" in the audio sense doesn't come into play until the data is moved out of the network buffer an is prepared for transmission to the DAC. At that point it becomes synchronous, is processed in real-time, and the clock becomes incredibly important.

 

The vast majority of the "reclockers" on the market (network or otherwise) are simple store-and-forward buffers. Nothing magic about them and, frankly, they're likely to do more harm than good. Remember, you can never make bit-perfect data more perfect, but you can sure as hell screw it up!

 

Thank you so much sir for making us understand the technicalities 

It was surely an eye opener for me 

So the preferred connection should ideally be the network input for streaming of data with the way it's implemented 

[shinyc]

6 hours ago, AMP said:

The vast majority of the "reclockers" on the market (network or otherwise) are simple store-and-forward buffers. Nothing magic about them and, frankly, they're likely to do more harm than good.

+10

 

There are at least 4 or 5 store-and-forward layers in sequence from the nic hardware until a packet reaches the user application. For one there is a common network algorothm employed by every OS called interrupt moderation. 

 

One should be more worried about newly introduced harming components like AC noise, network cable noise, EMI/EMF, etc. from those non-synchronous components in your system. 

[Confused]

9 hours ago, AMP said:

 

Reclocking is one of those words that is so overused in marketing fluff that it's tough to determine what it actually means. In fact, it's a made-up word that has no meaning at all

 

Network data (audio or otherwise) is transmitted asynchronously which by definition means that it is not dependent on any clocking reference that corresponds to any other clock. "Clocking" in the digital audio sense is only an applicable term when we're talking about synchronous transfer mechanisms like AES, SPDIF, SDIF, TOS, I2S, etc. While the physical layer of Ethernet relies on an oscillator to time pulses on the wire, that clock has no relation whatsoever to the clock in the DAC.

 

Furthermore, all network streaming devices (really all network devices) make use of memory buffers to temporarily hold the data packets and either re-packetize them for transfer back over the network or hold them for reassembly. In the case of a streaming device there's a memory buffer that's filled to a safe level from the network and metered out according to the audio clock rate. In the case of the network bridge the clock reference used to roll data out of that buffer is either one of the internal oscillators or an external word clock.

 

The "clock" in the audio sense doesn't come into play until the data is moved out of the network buffer an is prepared for transmission to the DAC. At that point it becomes synchronous, is processed in real-time, and the clock becomes incredibly important.

 

The vast majority of the "reclockers" on the market (network or otherwise) are simple store-and-forward buffers. Nothing magic about them and, frankly, they're likely to do more harm than good. Remember, you can never make bit-perfect data more perfect, but you can sure as hell screw it up!

This is interesting and very relevant to my current situation.  I have a dealer that is happy to lend me their demo Network Bridge for a few days next month.  I already own a Mutec REF10 and MC3+USB (probably one of the better "store and forward" clock devices)

 

Anyway, obviously I want to demo the NB in the best possible way that I can.  It occurs to me that there are different ways I could configure my set-up. 

 

1. I could use the REF10 to provide the reference to the MC3+USB, then simply run the system Ethernet to the NB, NB AES3 to the Referenced MC3+USB, MC3+USB AES3 to my Devialet amp.

 

2. I could use the REF10 to provide the reference to the MC3+USB, and then use the MC3+USB to provide a 48kHz word clock to the NB.  I could then run Roon up-sampling everything to 192kHz to the NB, and connect the NB direct to the Devialet via AES3.  (Also, in time I could add an additional MC3 to provide both 44.1 and 48kHz word clock signals to the NB)

 

I see 1) having the advantage of only requiring one external clock connection compared to two external clock connections for 2)

 

I see 2 as having the advantage of a more direct signal path to the Devialet.

 

Any idea which is best from a technical perspective?  Or is it a case of try it and see?

 

Other options would be to get the MC3+USB to provide a word clock to the NB, and feed the NB's AES3 feed through the referenced MC3+USB.  Maybe too radical or problematic?  A final option would be to run the NB without the Mutec kit, nice and simple.

 

Any thoughts on this would be appreciated.

 

 

[The Computer Audiophile]

3 minutes ago, Confused said:

This is interesting and very relevant to my current situation.  I have a dealer that is happy to lend me their demo Network Bridge for a few days next month.  I already own a Mutec REF10 and MC3+USB (probably one of the better "store and forward" clock devices)

 

Anyway, obviously I want to demo the NB in the best possible way that I can.  It occurs to me that there are different ways I could configure my set-up. 

 

1. I could use the REF10 to provide the reference to the MC3+USB, then simply run the system Ethernet to the NB, NB AES3 to the Referenced MC3+USB, MC3+USB AES3 to my Devialet amp.

 

2. I could use the REF10 to provide the reference to the MC3+USB, and then use the MC3+USB to provide a 48kHz word clock to the NB.  I could then run Roon up-sampling everything to 192kHz to the NB, and connect the NB direct to the Devialet via AES3.  (Also, in time I could add an additional MC3 to provide both 44.1 and 48kHz word clock signals to the NB)

 

I see 1) having the advantage of only requiring one external clock connection compared to two external clock connections for 2)

 

I see 2 as having the advantage of a more direct signal path to the Devialet.

 

Any idea which is best from a technical perspective?  Or is it a case of try it and see?

 

Other options would be to get the MC3+USB to provide a word clock to the NB, and feed the NB's AES3 feed through the referenced MC3+USB.  Maybe too radical or problematic?  A final option would be to run the NB without the Mutec kit, nice and simple.

 

Any thoughts on this would be appreciated.

 

 

I would try running the NB straight into the Devialet via AES without using the Mutec devices as well. 

[JamesBardsley]

On 6/26/2018 at 10:32 AM, The Computer Audiophile said:

I would try running the NB straight

Would the NB work into a Naim 272 DAC and preamp?

[The Computer Audiophile]

7 minutes ago, JamesBardsley said:

Would the NB work into a Naim 272 DAC and preamp?

It looks like that DAC has S/PDIF inputs on via RCA interface. The Bridge has an S/PDIF output on the same interface so it will work just fine. 

[JamesBardsley]

12 hours ago, The Computer Audiophile said:

The Bridge has an S/PDIF output on the same interface so it will work just fine.  

Thanks. The dCS NB is Roon Ready. Does this means it can act as a Roon endpoint, but not run the Roon Core? As I understand it I'd have to get the Roon Core running on a Roon Nucleus or a NUC or a PC or similar as well.

This is important from a budget planning POV as well as a box count, connectivity and technical POV.

I was planning to get the dCS NB instead of Roon.

My worry is that the dCS app will not be good enough to keep me using it forever, so I'll end up on Roon anyway.

If I'm getting Roon anyway, then the MQA unfold comes with that.

So then the dCS NB becomes a very nice but very expensive Roon endpoint.

So really I should spend that budget on a Roon Nucleus and a new DAC that is a Roon endpoint.

Does that make sense?

Any thoughts would be appreciated.

 

[Paul R]

Just my $0.02 - go slow until you are sure what you want to do. 

 

My advice, go with a separate PC, NUC, Mac mini, whatever as your Roon Core server. Load it with disk drives or whatever you need, stick it in a closet, on top of a shelf, somewhere away from whatever devices you use to play the music. 

 

Then, choose those devices based upon what you like in a music player. I suggest low power discrete music players. My current favorite is a micro Rendu, which requires a separate DAC with USB input. There are of course, as many configurations as you can imagine, and almost all of those configurations will sound very good. Some better than others, of course, 

 

But the point is to get those two functions separate. All-in-one units are nice, until you run into their limits or possibly if the manufacturer gets snippy with you about support. You will be amazed how much happier your life can become when you separate it out. Any problems with the server are computer problems, not musical issues!

 Not to mention, your phones and tables all become Roon Endpoints as well. Perhaps not the best sound in your home, but so convenient! 

 

Again, YMMV, other people may disagree. etc., etc., etc... 

 

-Paul 

 

[One and a half]

6 hours ago, JamesBardsley said:

Thanks. The dCS NB is Roon Ready. Does this means it can act as a Roon endpoint, but not run the Roon Core?

 

The dcs Network Bridge is a Roon Endpoint, it doesn't have the horsepower to run Roon core, nor any facilities to install such an app.

[JamesBardsley]

19 hours ago, The Computer Audiophile said:

The Bridge has an S/PDIF output on the same interface so it will work just fine.  

Thanks. Yes, I looked that up since asking it earlier today.

I think if it's a toss up between Roon and the dCS NB then I should go with the dCS NB as this will cost about the same but it should improve the SQ of my syste significantly more than Roon.

Correct?

 

[Paul R]

17 minutes ago, JamesBardsley said:

Thanks. Yes, I looked that up since asking it earlier today.

I think if it's a toss up between Roon and the dCS NB then I should go with the dCS NB as this will cost about the same but it should improve the SQ of my syste significantly more than Roon.

Correct?

 

 

Umm- your question confuses me. The dCS is not a competitor for Roon, it is a Roon “endpoint” - like a Rendu, or a computer running the Roon Client. In fact, the dCS is a computer.

 

You will still need Roon, or AirPlay, or one of the various UPnP servers to send music to it.