Differences in sound: DAC vs. DAC + Pre-amplifier

[barrows]

54 minutes ago, Kimo said:

 

Could you please elaborate on the modern new exotic engineering revolution that has magically made crossover distortion disappear?  I think some of those bad engineers like Nelson Pass would be interested in learning how to improve their designs.

 

 

This is not news, or anything new.  Class A/B amplifiers have been equalling or outperforming class A for a long time now.  

 

I suppose you do realize that Pass Labs makes both Class A and Class A/B amplifiers, right?

 

Please do not put words in my mouth, I did not call anyone a bad engineer, and certainly not Nelson Pass who I have an enormous amount of respect for.  

 

I find statements such as the above inflammatory (and maybe emotional?) and not conducive to good discussions in any way, perhaps you might like to re-think your approach.

 

As to excellent class A/B designs with low levels of distortion, I suggest you might have a listen to a Bricasti M-25 or anything from Constellation, perhsps...

 

I used to own a Pass Labs, class A/B amplifier, but after quite a few direct comparisons, over the course of a year, i ended up preferring my DIY Ncore based amplifier, this experience was turning point for me.

[barrows]

24 minutes ago, The Computer Audiophile said:

I’ve had some strange issues lately that we’re resolved by putting a preamp between the DAC and amp. I don’t like that this was the resolution, but it was. For example, one DAC had very audible pops when using specific filter settings and switching sample rates. These were inaudible when using a preamp. 

Chris, that sounds like DC problem at the DAC output.  If the DAC exhibits DC problems like this, a preamp will sometimes eliminate them before they get to the AMP, as the preamp will have DC correction of some type (servo circuit, I believe int he Constellation gear).  Sometimes DACs will have a DC spike in between locking... a properly designed DAC "should" be muting its output to avoid this in between locking to new sample rates.  I have seen this in DIY DACs a bit, where we might not have the most sophisticated control software.  Raising the buffering in Roon can sometimes help this.

Of course, for a DAC designed to connect to an amplifier directly this would be considered a fault of the DAC design and the manufacturer should address it.

[barrows]

4 minutes ago, The Computer Audiophile said:

And that folks, is why Barrows gets the big bucks :~)

Hahaha!

 

I just checked Roon settings, try going to "device settings" and "resync delay" and increasing that buffer some.  This sometimes helps as it gives the DAC a bit more time to lock to a new sample rate.  With DIY DACs I tend to avoid mixed sample rate playlists for this reason, as the DIY DACs sometimes do not handle sample rate changes very elegantly.  I find a good test for these kinds of problems is running Roon Radio as then i get random changes of sample rate fairly often, i tend to keep the volume low for this kind of testing (if it is an unfamiliar DAC) just t be safe.

 

But in a commercial DAC this is something I would consider a fault, and should be addressed by the manufacturer.

[barrows]

28 minutes ago, davide256 said:

Would setting all rates to one upsampled value do the same?

In many cases yes.  These kinds of noises can be tricky to sort out, often it is related to the USB receiver code, but problems can also be attributed to streamer code, and the DAC chip and how its muting works.  Setting a single sample rate going to the DAC can fix almost all apparent "problems" with the possible exception of a POP at the first startup, as the DAC may default to a different sample rate when idle, and then have to reset to the new sample rate.

 

In most cases though, the DAC manufacturer should really be sorting out these issues ,by making sure that their muting circuit works appropriately.  Mastering engineers could be considered partly to blame as well, as they could solve some of these "problems" by having a short period (even 500 mS would likely be adequate) of digital silence at the start of a file-of course they cannot due this for tracks which are gapless, but by doing this at the start of an album it woudl ay least solve many problems which might occur there.  Some DACs also incorporate sophisticated PLLs which require considerable time before they achieve a lock, this can be another problem (although it can also reduce jitter considerably) where the beginning of tracks may be cut off by the DAC muting until a lock is achieved.

 

When all we had was CD players, this was much simpler, now with computer sources, which can be different in how/when they present the file to the DAC, it can be quite complex to get every DAC working perfectly with every source.

[barrows]

3 hours ago, mevdinc said:

New Lumin X1 has the digital volume Leedh integrated; lossless digital technology. 
I have been waiting for the Leedh digital volume implementation for sometime, and I hope most DACs use. Absolutely no need for an additional preamp for me, as I only listen to digital sources.
There's a review over on 6moons website.

I am curious, where did you get the information that the X-1 has an LeedH volume control implementation?

[barrows]

As I am fully committed to sending DSD 256, the LeedH VC is not really applicable to my approach (unless it was in the server) and in the server, i suspect there is nothing better than what Jussi already does in HQPlayer.  But it is cool to see Lumin incorporate it.

I wonder whatever happened to the "rumor" that Damien was going to integrate LeedH into Audirvana?

[barrows]

22 minutes ago, matthias said:

 

Agree, 

AFAIK, for applying the Leedh VC DSD must be converted to DXD and then back to DSD.

Jussis algorithms are much more sophisticated, AFAIK he does VC for DSD in DSD domain.

AFAIK, no Leedh VC for Audirvana.

 

Matt

Hmm, LeedH will not even operate in DSD wide?  If that is true then even the volume control in the ESS chip works better than LeedH for DSD, as it operates in DSD wide (it does not reduce sample rate, it just converts the DSD to multibit, but keeping the high sample rate).  If LeedH down converts to 352.8/384 that is a backwards step for DSD.

 

Jussi does not disclose how his VC works, but I assume it is at least in DSD wide.  Of course with the computing power required for HQPlayer, there are probably a lot of tricky options, and Jussi is really, really sharp!

 

I have never seen a published description of the workings of the LeedH, is there one anywhere?

[barrows]

24 minutes ago, matthias said:

 

Maybe here:

 

https://6moons.com/: "pioneer of DSD streaming"!/lumin8/

 

and here:

 

 

Matt

Thanks for the links.  A lot of plain wrong info in the 6moons blurb on it though, oh well.  Heck if folks like it. great!  But it does not appear to offer any real advantages vs a 64 bit volume control, such as implemented in Roon (although that does not work on DSD either as Roon will not enable it for DSD).  Also, I am a bit taken aback by the false statement in the 6Moons amp review that Lumin is the "pioneer of DSD streaming"!  I guess this reviewer needs to do a little more homework before making such untruthful statements.

It looks like the only advantage of the LeedH VC is if one is attenuating to -60 dB or more, and then, only vs. the volume controls built into DAC chips like ESS that typically are 32 bit.

What a lot of people never seem to talk about when criticizing digital VC is they get right the idea that at high levels of attenuation you will lose some low level details, but they do not point out that if one is listening that quietly, there is no way one would hear details that low in level anyway.   The only real world exception to this would be for those system with very, very poor gain matching, where folks are regularly turning it down to -60 dB or more for regular volume levels.

[barrows]

1 minute ago, mevdinc said:

At one point it was said that Audirvana would be one of the early adapters. But, still no news.

Perhaps Damien (a pretty smart dude) realized the LeedH actually offered no real improvement.

[barrows]

I prefer the opposite way:  As much processing as possible before anything gets to the DAC, and then the DAC just converts to analog and buffers the signal for delivery to an amplifier stage.  In any case, a digital VC inside a DAC still makes its attenuation before the conversion to analog...  Everytime I reduce processing done internally in the DAC, I hear a step in the right direction in sound quality.  This is why I oversample to DSD 256 in a computer isolated by an optical Ethernet Renderer and then the ESS chip in my DAC does less processing on the signal.  Less processing in the DAC (all other things being equal) always results in a more natural sound for me. 

 

[barrows]

29 minutes ago, matthias said:

 

OK, for some DACs processing helps as @barrows mentioned.

 

Matt

Well, indeed...  And the R2R DAC you mention will perform better (if it does not OS onboard) with an oversampled signal objectively.  Whether a listener prefers the sound of a totally NOS approach is a different matter, but such a preference is not one for accurate conversion.

 

The one thing that is unavoidable though, is that a computer will always be able to run a more sophisticated, and more precise, oversampling calculation than any DAC due to much more processing power available.  And it is much easier to avoid problems caused byt the processing (mostly processor noise/RF) if that processing is done far away from the audio system.

[barrows]

10 minutes ago, mevdinc said:

Having Leedh in software player such a Audirvana would be another great option to have. This option would work with any DAC.

The above is only true if the LeedH volume control was actually superior to what Audirvana already does.  As the 6moons article says, LeedH is only superior to a 32 bit volume control (not 64 bit) and, only when there is a lot of attenuation (-60 dB).  to license the LeedH, Damien woudl have to raise the price of Audirvana and as far as the descriptions go, there is no advantage.

Now i will admit that the descriptions given are rather cryptic and not precise.  I do not think it would be a "great option" to pay ore for a volume control with no actual advantage in use.  I suspect this may be why Damien did go forward with LeedH.

 

But we should not just view this so simplistically,  LeedH is not "lossless", it just has less loss than a typical 32 bit volume control when operating at -60 dB or less.  So, if one is using already a 64 bit volume control, as in Roon, for example (I cannot remember if Audirvana is 64 bit) there is no advantage at all to LeedH.  Additionally, if one does not regularly need -60 dB of attenuation, there is also no advantage to LeedH-At leads that is what the description of how it works at 6 moons says...

 

It would be interesting to hear @Miska's analysis on this, as he is one who could certainly offer a more considered and detailed view, and he could add his thoughts via a vis LeedH vs HQPlayer VC.

[barrows]

22 minutes ago, matthias said:

 

I am not strictly talking about NOS DACs. There may be DACs which take a benefit from software upsampling but certainly not all. Even in lower price ranges like Schitt Yggdrasil the from Schiit implemented OS algorithm might be better than software upsampling. The Yggdrasil seems to work extremely well with Redbook content. Other DACs in higher price ranges like the APL, Emmlabs, Ypsilon, Chord etc. have either implemented their own OS or the manufacturers recommend playing bit-perfect for best SQ. 

The Taiko keeps computer activity at minimum for best SQ on the other side do exist the EC filters and modulators from Jussi which are so demanding that no consumer computer is able to reproduce in DSD512. 

 

Matt

 

 

 

This way off topic, but I feel it is OK because the topic is mostly dead anyway, if the OP minds, please ask me to shut up and I will.

 

I do not entirely disagree, but I would suggest that it is possible to implement a better oversampling algorithm in a computer than that which is done inside a DAC.  The advantage of using a much more powerful processor allows for a better oversampling algorithm than what any of these DACs you mention can do.  You can believe in "magical" formulas by DAC makers, or you can believe the actual truth, that any oversampling algorithm used by any of these DACs, can be done better, with more precision, in a powerful computer.  The other factor is that any processing done inside a DAC has the potential to pollute the DAC with noise, as these processors, especially the more powerful FPGAs such as used by Chord are quite noisy: Chord themselves admits that the reason they make the mScaler, as a separate component is to remove it as noise source inside the DAC.

 

Yes indeed, the noise produced by a  computer is a problem if not dealt with.  The best way to do this is to isolate the computer from the audio system: This why Jussi makes NAA.  By locating the computer in another room of the home, it can be as massive and noisy as necessary tor any kind of oversampling, and can have fan cooling, and hooking it all up over Ethernet (optical Ethernet is the best) isolates all the computer noise from the audio system and DAC.  This approach also makes crazy expensive "audiophile" servers unnecessary, saving cash (take your girlfriend out for some nice meals perhaps).  All you need is the best ultra low noise Renderer you can get in your system, and all the other computer gear can be basic commercial stuff, as the optical Ethernet connection isolates all the noise.

[barrows]

I have only one more thing to say and then I shall bow out.  Extraordinary claims, which go against the laws of physics, require extraordinary proof.  Extraordinary proof would be actual measurements showing improved DAC performance (I would accept a measurement of noise floor and an accurate jitter spectrum) in a addition to blinded listening tests which correlate with the measured results in a statistically significant fashion.  While I generally believe in subjective evaluations, I am highly suspicious of such when it comes to claims which are clearly violating the actual engineering concepts which are at play here, especially when we are talking only about digital data and not analog factors.

[barrows]

Guys, nobody achieves 21 bits of resolution in room, so there is no advantage to a DAC which achieves 21 bits of resolution at its analog outputs vs 20 bits, or even 18 bits.  When a DAC gets beyond 17-18 bits of resolution it is a moot point for listening to speaker systems in a  room.  If one is willing to risk their hearing in a headphone set up at extremely high levels of playback, then maybe 19 bits is meaningful, but for speaker systems these high levels of resolution mean nothing in the real world.

[barrows]

31 minutes ago, audiobomber said:

I agree with all that. All I'm saying is that you need at least a 32-bit DAC if you are using the DAC as a preamp. A 24 bit DAC is insufficient.

It also depends not the gain matching in your system, so let's not forget that (I realize you know this, but for the folks just reading along).  In my system, for example, I am never listening critically with more than -18 dB of attenuation, so that is ~3 bits of attenuation.  Even if the volume control was only 24 bit in the DAC, I would be left with 21 bits of resolution.  

Even the above is moot anyway, as all the digital volume controls I am aware of in use now are 32 bit or 64 bit.

 

Now the other issue is for DSD.  Anytime we control volume in the digital domain for DSD we have to re-modulate it, and as experience with HQPlayer shows, re-modulation really matters to sound quality: it needs to be done really, really well.  Luckily, Jussi has figured that all out for us and the volume control in HQPlayer is exceptional.  That being said, I am soon to receive a Bricasti M3 DAC, which runs a single bit path all the way through for DSD input-this DAC incorporates an analog volume control (which is bypassable) so that it can control the DSD volume.  So it will be interring to compare HQPlayer's VC and the analog one.

[barrows]

10 minutes ago, audiobomber said:

2) I suspect that having a common clock for streamer and DAC may benefit PRaT. I have not been able to test this, never having heard an ethernet DAC. The Auralic Altair G1 seems to excel at PRaT from the sonic descriptions I've read.

The above is not possible, the clock frequencies required for Ethernet transmission and audio data are different.

 

While I agree that a direct ethernet connected DAC is a desirable thing, in practice it is very difficult to implement a good Ethernet interface inside a DAC.  By no means am I suggesting it is impossible to do so, but doing so does require paying attention to a lot of details.  Decoding Ethernet data to digital audio samples requires quite a bit of processor power, quite a bit more than, for example, USB audio processing to digital audio data.  And even USB interfaces inside DACs benefit a lot from careful implementation and isolation.  For example, a typical USB interface requires around only 200 mA of power at around 5 VDC, whereas even a less capable (sample rate limited) Ethernet interface requires at a minimum 500 mA of power at 5 VDC, and a better Ethernet interface (like Sonore's optical) requires well over 1 A at 7 VDC to work with higher sample rates.  This power requirement transfers fairly directly into processor noise, inside the DAC chassis.

Currently, most DACs (not all) with inbuilt Ethernet interfaces are both sample rate limited, and not adequately isolated from the DAC circuitry.  Mostly this is because most DAC companies are quickly adding Ethernet interfaces using relatively affordable, off the shelf modules, of limited performance.  One exception is Lumin, and another is Linn, although while the Linn Klimax DS provides superb performance, it is still sample rate limited.

 

The way to do it right:

 

1. Design your own Ethernet interface (preferably with optical input for noise isolation), capable of all sample rates to PCM 768 and DSD 512 (or higher).  And be sure to use high end design approaches all around, many low noise regulated supplies, high precision ultra low phase noise oscillator, etc, etc.  Not an affordable off the shelf module.  Designing such a module requires an engineer highly skilled in high speed circuit engineering, preferably someone with extensive computer mother board design expertise, typical engineers at audio companies do not have the required expertise for this, so the dAC manufacturer will likely have to sub-contract a suitable engineer for the project.

 

2. Make sure the digital audio output (I2S) from he Ethernet interface is fully galvanically isolated from the rest of the DAC.  Note that to provide full galvanic isolation it is also necessary to supply power to the Ethernet interface from a dedicated supply, preferably from a separate dedicated transformer.

 

3.  Make sure the Ethernet interface is physically shielded in a separate sub enclosure to reduce the amount of airborne RF pollution on the inside of the DAC chassis which can couple into the analog outputs.  Note that both Lumin X-1, and Linn Klimax DS do appear to address this need, as does the Mola Mola Tambaqui.

 

I would expect to pay around a $2K USD premium for a really good Ethernet interface inside a DAC, all other things being equal. This can come at some savings if the DAC maker is willing to forgo other inputs altogether, which would be my preference for best sound quality: simple has its advantages.  An Ethernet only input might be able to come with a $1.5K USD premium over the same model DAC with only typical inputs.

 

 

[barrows]

3 hours ago, R1200CL said:

So this is what John Swenson is working on 😀

To be perfectly clear, I do not speak for John Swenson and my description of how to incorporate an Ethernet interface internally in a DAC was a general proposition.  I was trying to point out that it is very important, that if one is looking for a DAC with an included Ethernet interface, that one be sure to choose one with an excellent interface and implementation.  Just having an Ethernet interface is not enough.

Despite Linn's (and Logitech, and Lumin) extensive experience with Ethernet, for most audio companies, we are in the early days of Ethernet audio interfaces.  And just like the early days of USB interfaces, it is going to take some time before audio companies get up to speed with getting their Ethernet interfaces working without compromises (both in performance and sample rate capability).

[barrows]

5 hours ago, wklie said:

 

To the best of my knowledge, Lumin was the first network player to add DSD support to UPnP network streaming back in 2012.  We ran into several difficulties.  UPnP media servers at that time would not even stream DSD files.  So we supported DoP file as well - and we contributed to the preparation of DoP file.  (Now Roon refuses to support DoP files, so we have Lumin users with DoP files finding that Roon would not play them.)

 

If you can let me know which product directly supported DSD over UPnP network playback in 2012 or before that, I'd appreciate it.

I must admit I am not aware of a Lumin Renderer available here in the US in 2012.  Can you educate me with some of Lumins' history?

[barrows]

5 hours ago, tedwoods said:

Why put an ethernet to i2S interface inside a DAC?

Because that is what I2S transmission is designed for.

Using I2S between components, especially how it is generally implemented now (the PS Audio protocol) is a flawed approach.  Commonly used I2S transmission between components right now generally uses LVDS signaling, which is a balanced version of I2S.  It is good that it is balanced signaling, but it must converted at each end from balanced to single ended through LVDS chips.  These chips add jitter at each end.  Additionally, the current way I2S is implemented makes the source the master clock generator, meaning, just as with SPDIF, the DAC must use the source clock as the master.  this is also the wrong way to get low jitter conversion.  For low jitter conversion you want the master clock as close, physically, to the conversion stage as possible.

 

Now, you can overcome most of the above obstacles through heroic engineering efforts at asynchronous I2S reception, and fully asynchronous re-clocking to a local master clock, but just as it is with SPDIF, engineering a fully async I2S receiver is tremendously difficult-because, unlike USB audio, there is no way to speed up or slow down the transmission from the source, so managing the buffer to not have overuns or underuns is very, very difficult.

 

It is much easier to make a low jitter, "perfect" digital audio interface, with USB, despite the many folks' opinions that USB audio is somehow flawed in nature.

 

Still, my "Ultimate DAC concept" would have an optical Ethernet input (only), which was well isolated from the rest of the DAC internally: with its own separate power supply, inside its own separate shielded sub enclosure, and completely galvanically isolated from the the rest of the DAC.  Then you can have a single master clock for the DAC section, adjacent to the conversion stage, and this clock can remain clean and undisturbed by any other clocks.  (As any other clock frequencies used will be in the isolated Ethernet receiver section).

[barrows]

22 minutes ago, matthias said:

 

The biggest drawback of this concept for me is that you can use this kind of DAC as endpoint only and not connect directly to a high quality server via USB.

The experiences with very good servers show that a direct connection of a DAC to the server via USB does sound better than using the same DAC with an endpoint which in this case would be an Ethernet-DAC as combi of both.

 

But as always YMMV

 

Matt

 

Yeah well, my experience is the opposite, and there is also absolute zero technical evidence to support the above, in fact every technical metric points in the opposite direction.

 

No matter how ridiculously sophisticated a custom server is, it can NEVER have a noise profile which is as low as that of a properly designed and engineered Ethernet Renderer, it is just not possible.  So, if one prefers the sound of a server to the properly designed and implemented Ethernet renderer, the only logical conclusion that one can draw, is that one is preferring the noisier component, and the extra artifacts which the DAC produces when connected to the noisier component.

 

[barrows]

28 minutes ago, hopkins said:

How do you ensure "perfect galvanic isolation"? With what technology?

 

A lot of stuff there I put in quotes, usually when I put "perfect" anything regarding electronics i put it in quotes.  Perfect in this sense is a concept, which may never be achieved, or it might be in some instances,

 

In any case, different engineers have different preferences when it comes to which isolation technologies to use.  These are used to isolate USB interfaces from the rest of the DAC as well.  Some are GMR based isolation chips (these are magnetically based on a chip), some choose optical isolation chips, some use capacitive isolation chips, and some might choose to use larger magnetics (non chip based transformers).  I am not a high speed circuit designer, and have no opinion on which approach might be best in any given situation.  But I have plenty of experience comparing isolated USB interfaces to non-isolated USB interfaces, and isolated is superior, and does result in a large degree of noise reduction from the USB interface to the DAC conversion and analog stages, nothing is perfect though.  But, the point being that if one wants an Ethernet interface inside a DAC (and I am one who does), best practice would be to isolate it by using one's favorite/best isolation approaches and maintain that isolation by powering it from a dedicated power supply, including a dedicated transformer.  Additionally, i would prefer an Ethernet interface to be physically shielded from the DAC circuitry in its own sub enclosure to avoid airborne RF interference.  Take a look at internal photos of the Lumin X-1 DAC, for example, it follows these design implementations

 

None of these isolation measures is going to be perfect though, nothing is (consider that there may be noise crosstalk at the AC input itself, for example), but such measures when done well have proven to improve DAC performance to levels where further efforts in this direction are probably not going to result in any actual audible change.

[barrows]

5 minutes ago, hopkins said:

- you are not specialized in this field

I am not a high speed circuit designer, as stated.

 

I have worked in high end audio for around 20 years now, often coordinating directly with very talented engineers who are high speed circuit designers, and I have had these discussions with them.  Isolation of USB and Ethernet receiver circuitry is a well understood and fairly mature technology, and there is not much debate about how to do it properly, it is accepted tech.

 

In addition, I have personally built 10-12 DACs (lost count) DIY, using various approaches, including isolated and non-isolated input receivers both USB and Ethernet based approaches, and have made direct comparisons amongst them.  I am totally convinced that when properly implemented, an isolated USB/Ethernet receiver is superior.  

 

So I both have direct experience of the subject matter at hand, and the experience of a handful of very talented and sharp high speed circuit engineers from whom I have learned a lot about isolating digital inputs.

 

13 minutes ago, hopkins said:

- you acknowledge that you are basing your claim on comparing what could very well be "imperfect" solutions

 

As mentioned, there is no "perfect" solution to providing isolation from the input receiver, all solutions will have some capacitive coupling across the isolation barrier (some more than others).  What is clear though, is that having isolation is superior to not having isolation, as the level of noise which can get across the barrier is much, much less than if one just has a direct electrical connection and no isolation.

 

I am really unsure as to what your motivation is here?  It is generally accepted that it is proper engineering to isolate noisy digital audio interfaces which include high speed processing chips (USB or ethernet qualify for this) and most well implemented USB DACs, and some Ethernet DACs do exactly that: I am not exactly advocating for anything controversial here.  Is there some other approach which you would advocate for or something, or are you just looking to create Internet based tensions?

 

 

[barrows]

7 minutes ago, EvilTed said:

Well having owned the Sonore Optical Rendu, Optical Module and Uptone JS-2 Supply, I can tell you that the Lumin X1 is far superior  to the front end I had before.

It may have been the age of the DAC (BADA Series 2) but whatever the Lumin X1 is doing, it works great.

I also like the fact that it is well made and a single box solution that I just put fiber in and take balanced analog out.

If you want to deal with a lot of boxes and wires (and their individual ground connections), go for it.

 

I would encourage people to actually hear the X1, preferably in their own system and then decide.

 

 

I heard the X-1 at RMAF last fall, I agree it sounds great!  But that is a DAC, and I am not sure what that has to do with Sonore Renderers, they are not rally comparable products?  Not that my posts here have anything at all to do with Sonore products anyway... we were talking about DACs, right?

[barrows]

Just now, hopkins said:

There actually is debate about its efficacy! 

Umm, what debate would that be?