dCS Bartók Streaming DAC + HP amp

You can use an alternate UPnP control app to feed Qobuz to any of our products. BubbleUPnP on Android and mConnect on iOS both work.

OK great, so would that work like google cast, with no loss of resolution and gapless?

If you have this possibility I’d do it like a flash.

1 Like

Dangerous suggestion, Andrew.
My own listening session had quite some consequences, including investing in a Rossini …… and now suffering through the wait for Rossini 2.0
:slight_smile:

1 Like

Thanks Ludwig! I wish I could do it without any worry, still a lot of money even they allow me to trade the Bridge for full value up for the Bartok. I would be upset if the improvement is only marginal…haha. let’s see what happens.

Thanks Jacobacci! One thing I am waiting to hear from dCS is their design inside Bartok, essentially they are putting the Bridget and a newer Debussy into one box called Bartok. I thought dCS is always the advocate for separate boxes which eliminates EMF, interference, or whatever between different components (of course that requires more money and high quality of interconnects). I want to hear from them how they manage those noises inside one box and how the circuit board connection between the network card and the DAC section is superior to SPDIF or USB. Initially i thought that one box solution is the solution for the drawback of SPDIF and USB that we talked about here and improve SQ. But now i am getting some mixed feeling that the one box solution alone doesn’t make SQ better. Complicated but fun. Good to learn from you guys for sure.

One experience to share - I auditioned the older Debussy DAC for 3 days at home, to a/b test against my previous Chord 2Qute DAC (before Qutest was launched). I was expecting some reasonable SQ improvement given the huge price delta between the two. Unfortunately, even i really wanted to get a dCA DAC and that discontinued DAC was at deep discount, I tried really hard but still could not hear any “reasonable” SQ improvement. The dealer was nice enough to lend me very expensive interconnects but still did not help. It was either my ears were not golden ears or Chord did find an efficient way to make its DAC sound good. Anyway, I returned the Debussy (combined reasons between the disappointed audition and the aged/discontinuing hardware), and later got the Qutest.

I am quite sure Bartok would sound better than Debussy, but i am concerned that the SQ improvement is only 5%, for example (sorry i should not quantify it but i guess you know what i meant), as the price of Bartok is 2 times Bridge + Qutest. Itchy but worried…LOL

Anyway, learning all these from you guys before going to the dealer really helps, so thanks again.

This is not what Bartok is, but that’s a subject for a different thread. Lots of info here:



Typically the timing of the input signal is recovered and input into a phase locked loop (PLL) circuit to bend the DAC’s clock to match. This isn’t an ideal approach as recovering the timing over S/PDIF can be problematic due to a number of factors (impedance mismatch, cable reflections, external noise, etc). Unfortunately, in lieu of a separate clean clock signal it’s what’s available.

I love how audio engineers make up words that don’t exist in the wider world of engineering. Not a dig at Chord (or anyone in particular), but more of an observation that in an effort to over-simplify things high-end audio tends to create a language that has no basis in reality.

You’ve got two options with S/PDIF:

  1. Recover the clock signal from the source, feed it into a PLL, and operate both components in one clock domain.
  2. Dump the S/PDIF signal into a buffer and read it out using the DAC’s local clock. This then leads to the same issue of filling and draining buffers. Since there’s no way to tell an S/PDIF source to hold on a sec or send faster then something bad happens eventually. The way that this is handled ranges from ugly to elegant.

I’m not sure what Chord is doing in their product.

Filter taps and jitter are apples and sunglasses. There’s absolutely no relation between them and a filter isn’t going to magically eliminate timing errors. The clock drives the DAC and the DAC performs one operation per clock cycle. If the clock is fast then the DAC is fast. Period.

In a DAC the clock is analogous to the pitch control on a turntable. Spin the platter fast and the pitch of the audio is high. Spin the platter too slow and the pitch is low. Cause frequent and minor adjustments to the speed (fast and slow) and the audio is… strange… unnatural. <<< That’s jitter.

3 Likes

Hi Andrew, which component in my setup is the “Renderer”, and/or how does Renderer fit into the RAAT framework? I have seen this term many times but always confused what it is and what it does. Previously I thought the Bridge is the Player/Renderer, but now I know Player is the Roon Core per Roon’s definition, and the Bridge is nothing more than a high end “network card”.

Thanks for showing me the signal path with Bartok, which eliminates the 3-step SPDIF implementation. It makes sense that change alone could potentially improve some SQ. However, I wonder how the network card (presumably a simpler version of Network Bridge) and the DAC section are connected/communicate inside the one box Bartok? How is that internal connection superior to SPDIF or USB (other than no interconnect required)?

I am more interested in the Bartok without headphone amp, which is why I previously and generally said Bartok = 2-in-1 Network Bridge + Debussy (functionally). Putting the better and newer DAC aside, and assuming the simpler signal path without interconnect would pick up some SQ, will this 2-in-1 design introduce higher interference to both the network card and the DAC section? Are there two separate power supply inside Bartok, one for the network card and one for the DAC?

Thanks Andrew!

You’re getting way too hung up on vocabulary here. The term renderer is used a lot, but there isn’t a solid definition to it as it pertains to audio. It can be any of the following:

  • DAC - takes an incoming digital bitstream and converts (renders) it to analog
  • Network bridge device - Takes an incoming network stream and converts (renders) it to AES, S/PDIF, etc
  • The second stage of the MQA process is also known as the renderer (as in MQA renderer)
  • Plenty of other things…

I’m not going to go into an in-depth architectural discussion here, but will say that the streaming card and DAC have a number of communication lines and methods by which to exchange information and digital signals. There is a lot of communication that goes on between the two.

The network cards in Bartok and the Network Bridge are very similar and run the same code.

The internal connection is I2S which includes separate data and clock paths including separate bit and word clocks. This is the standard for moving digital data over short distances (within a device). It has very low overhead and is extremely robust.

USB and S/PDIF rely on some other carrier mechanism(s) to move data and deal with clocking. Neither is ideal for digital audio within a component as they both require several additional layers of complexity over I2S. (there’s also the detail that neither one of them was developed as an ideal way to move digital audio - S/PDIF was designed to encapsulate digital audio for recording to a video tape recorder and USB was originally designed as a low-speed asynchronous transfer bus for computers).

I2S was designed to move audio data. period.

That’s the best part of the Bartok.

No. Our engineers are really good at dealing with these things. Sure, you aren’t going to get the level of isolation you get in a Vivaldi, but that has a much higher cost associated with it.

If sound quality is your primary concern then Bartok is going to be better than Network Bridge + Debussy.

There is one transformer inside the Bartok DAC which feeds a number of isolated and separate power supplies responsible for all aspects of the device’s function.

1 Like

Thanks Andrew! I think another benefit with Bartok is that the DAC section will receive up to 384/32 PCM and DSD256, without being capped by the SPDIF output on the Bridge (only 192/24 and DSD64), which makes the upsampling beyond 192/24 by Roon meaningless.

I will go to one local event to listen to Bartok, I guess I will be in trouble after that :). Let’s see…haha

That’s 24/384 and DSD128. It’s the same for all of our products.

1 Like

Are you guys going to be at CAF next month?

Hi Andrew, now I can focus on the DAC inside Bartok.

One important thing I noticed is that the DAC inside Bartok is still called Ring DAC, but it now upsamples all incoming signal to DXD as standard, and DSD as optional. I recall that Debussy upsamples all incoming signal to 5-bit DSD as standard, which is known for Ring DAC. There is a specific reason for upsampling to 5-bit DSD, but not 4-bit or 3-bit.

(1) Why does dCS now make DXD upsample as standard? Is it because PCM is less noisier than DSD?

(2) what level of DXD Bartok upsamples to? Could not find the numbers on the site.

(3) for the DSD upsampling, is it still doing 5-bit?

(4) I would think upsampling by Bartok (or other high quality DACs) is fundamentally better than upsampling by Roon. However, I have heard argument that having Roon to handle upsampling will release the DAC from that burden so that the DAC can focus on what is good at, digital to analog conversion. Which argument is right?

(5) let’s say I use Roon to upsample to 384/24, which is the max Bartok can take from Ethernet, does Bartok stop or skip the upsampling step (I assume Bartok only upsamples to 384/24 on the DXD option) and go directly to do digital to analog conversion?

Thanks!

This is likely coming from a review which provided some information which wasn’t exactly correct on a technical level.

All of our products use the RingDAC architecture and Bartok is no exception. It uses the current architecture which is shared by Vivaldi, Vivaldi One, and Rossini.

The RingDAC is designed to operate on a specific data format which is 5 bits with a sample rate of either 3 or 6MHz. It’s not DSD… it’s RingDAC format. It’s 5 bits because that’s how the math works out in relation to the actual physical hardware and desired noise characteristics.

Most DACs do some form of up/oversampling of the bitstream prior to feeding it into the DAC core. We’re no different there. DXD is standard as that’s the typical operation that’s done. DSD is an option for those who prefer it. There’s no advantage or disadvantage for either one.

DXD is, by definition, 24 bit PCM at a rate of either 352.8KHz or 384KHz depending on the base sample rate of the incoming stream. Fun fact, dCS pioneered DXD.

DSD upsampling is taking the incoming bitstream and upsampling it to DSD64 using our proprietery sigma-delta modulator. That is input into the processing core and converted to RingDAC format later.

FPGAs excel at functions like upsampling and our algorithm and filter set is excellent. I won’t make a comment on which is better, but I’m willing to bet that you could guess the right answer. Upsampling isn’t a burden for our platform, it’s what it was designed to do.

If it’s 24/384, there’s nothing to upsample, now is there? The processing steps after that stage are the same.

Thanks for the elaborate answers. I am quite impressed and fascinated by the technical feats of the current dCS line of DAC/Streamers.
Unfortunately i have only heard them in show context so far.

The screenshots above are from dCS website under Bartok specs, not from any third party source. Did I misunderstand its meaning?They read to me that I have options to upsample to either DXD or DSD. Sorry if I misunderstood it

The upsampling takes place before the audio stream is processed in the Ring DAC (which always uses a high sample rate bit stream with a bith depth of 5bits).
So you can choose what kind of ingredients your chef (the RingDAC) has to work with. The result will most likely be delicious regardless! :wink:

1 Like

This definitely sounds like a solid technical design. I have never understood why anyone would build today either extreme of the old technology DAC designs: NOS R-2R vs Single bit DS. NOS R-2R suffers from differential non-linearity but has low noise. Single bit DS DACs suffer from high noise levels but have excellent linearity. Both of the older approaches are flawed, just in different ways.

To me a 5 or 6 bit DAC is the optimal marriage of both the old technology designs - excelling at BOTH low noise AND linearity.

2 Likes

Thanks Mikael for your explanations. I understand that the upsampling happens before the signal goes into the DAC Core. My question to Andrew or my curiosity was whether DXD upsampling is new to dCS DAC (or just something that Debussy did not have) and why the new option for DXD upsampling becomes default or standard as the dCS website described. I only auditioned Debussy before so probably there are different levels of Ring DAC, some has two options and some has only one?

I was a little confused when Andrew said the DXD upsampling info is probably from an untechnical article, so I just want to clarify that I found the info from dCS website and make sure I did not miss anything. I have no engineering background so I may not incorrectly interpret or read into the technical words. Sorry Andrew if I misunderstood your explanation as to the DXD option :blush:

Thanks!

Man, just listen and decide! :wink: I understand you, me and everyone else wants to make informed, wise decisions though.

All current dCS products share tha same Ring DAC as far as i understand. And yes, this Ring Dac has been redesigned since the Scarlatt/Puccini/Debussy generation.

I think the options for filtering the audio BEFORE it hits the RingDAC can be made in different flavours with DXD(PCM) and DSD. Anyway, if dCS has chosen to set the DXD upsample as default i’m sure it’s because they feel it performs better than the DSD counterpart.

As for me, i chose another DAC altogether and it was the Nagra HD DAC.

Let us know how you procedd? It’s interesting to know what choices people make and why! And you seem like aguy who makes really informed choices! :slight_smile: