USB audio cracked... finally!

[Jud]

2 hours ago, scan80269 said:

So I don't doubt different USB cables can result in different sound.  Immunizing a DAC against the effects of a USB cable connected to it has not been trivial and there hasn't been a lot of success cases AFAIK.

 

 

In purely subjective listening, @PeterSt‘s Phasure DAC was the best I’ve ever heard at this.  I think he may have gone in a bit of an other direction since, but it shows he knows how to do it if he wants.

[Jud]

5 minutes ago, acg said:

 

Also he has paid specific attention to dielectric and other effects more commonly associated with analogue cables.

 

Of course it shouldn’t be forgotten that in some respects “digital” cables do transmit analog signals.

[Jud]

46 minutes ago, scan80269 said:

A few excellent DACs today (Phasure? Berkeley?) are already so good they don't benefit from the USB tweak boxes.

 

Phasure has recently installed its own built in “tweak box,” the Phisolator, yet the sound is still at least purportedly affected by the USB cable.  Berkeley has for a long time had its own separate USB/SPDIF converter.  So we still appear to be a little way from at least these manufacturers attaining immunity from upstream influences in a fully USB chain.

[Jud]

1 hour ago, pkane2001 said:

 

Sure, Peter. That could actually be an explanation. The fix, then, is a better power isolation, or even separate power supplies to the two sides of the DAC USB receiver.

 

Hi Paul.

 

@PeterSt believes this must have to do with current draw.  John Swenson, as Peter mentioned, believes it has to do with injecting noise onto the DAC’s ground plane because the USB receiver chip must work harder.  In either case, these effects would then in turn affect the DAC’s clock and/or the zero crossing point of the signal (determined by comparing signal to ground, the latter notionally being zero, but if there is noise on ground, it isn’t actually zero; you can read ESS white papers where much is made of noise reduction on the ground side).  I read a post from Gordon Rankin in another forum a couple of years ago that I interpreted as supporting the ground noise theory, but I don’t know enough to be sure I was interpreting correctly.

 

I don’t know of confirming measurements for either hypothesis at this point.  Because we’re talking about an effect happening in the DAC clock as it’s working, I think the measurements would have to be in the analog domain; or, as John Swenson once mentioned to me, you could essentially build the world’s most precise ADC.

[Jud]

OT: BTW, @PeterSt, Verstappen or someone else?

[Jud]

7 minutes ago, PeterSt said:

 

Haha. Hamilton. Verstappen was 4th.

But someone from Holland (Bauke Mollema) just won an etappe in the Tour the France. Also rare.

 

Right, I watch all the races (and qualifying).  But is Hamilton your favorite driver?

[Jud]

26 minutes ago, austinpop said:

So - 7 pages of discussion of why this or that can or should sound better. 

 

You’ll thank us later.

 

But yes.

[Jud]

34 minutes ago, manisandher said:

 

Absolutely it is.

 

It's quite a claim from Schiit though, and they're going to have to live up to it. Interesting that they're not offering the Gen 5 in a USB-to-USB isolator (only a USB-to-spdif converter, the Eitr) - if they had, it would have been easy for anyone with any USB DAC to verify their claim.

 

Mani.

 

Trafo isolation sounds like Ethernet.  Except that (Ethernet built-in transformer isolation) doesn’t always work completely to stop noise, as I found out in my system.

[Jud]

2 minutes ago, jabbr said:

 

There's also GMR which really is very similar to transformer: https://www.nve.com/Downloads/galv.pdf

 

Yep - John Swenson prefers them to on-board optical isolators (for USB?), as I recall.

[Jud]

1 hour ago, marce said:

There is still some capacitive coupling through many of these devices especially the Adum types.

 

Yes, I love the marketing copy that talks about “perfect” immunity or isolation.  Perfect is quite hard.

 

Very very good can be done with care and a little expenditure, though.

[Jud]

2 hours ago, manisandher said:

 

 

Hey Peter, what exactly did you mean by this?

 

Mani.

 

Heh - the discussion of USB frequently reminds me of what Winston Churchill said about democracy:

 

Quote

Indeed it has been said that democ­ra­cy is the worst form of Gov­ern­ment except for all those oth­er forms that have been tried from time to time.…

 

USB has the worst problems of any audio interface, except for all the others that have been tried commercially so far.   

 

This isn't to say better interfaces aren't to come, just that we should recall SPDIF, optical, and I2S have their own limitations and disadvantages.  AES/EBU may have its own problems as well, but I'm not sufficiently familiar with it to know about them.  (Can it be run async, with the controlling clock in the DAC?)  Ethernet is promising, but as we've been discussing, its galvanic isolation isn't a panacea; and thus far we don't have an interface available to consumers that will do the resolutions some folks like to run.

[Jud]

2 minutes ago, PeterSt said:

Audio (as in audiophile terminology) is a totally different world for uncountable reasons.

 

I know they are uncountable for you, as long as you've been in this (anyone looking at the number of controls in the XXHighEnd software interface can see that), but I have a feeling marce might like you to count some reasons. 

 

I'll go first: One XXHighEnd control helps to determine how much of the audio file is preloaded into memory before being sent along for playback.  Of course I wondered how this could affect the sound.  I then coincidentally ran into a thread on another audio site (Computer Audio Asylum) where John Swenson and Gordon Rankin explained how this could occur.  So effects can come from surprising angles.

[Jud]

22 minutes ago, marce said:

We use signal integrity software (as well as physical checking of waveforms) and only for the hard interfaces, if USB audio is that hard why do I see NO evidence of proper signal integrity engineering...

 

@marce, if you were willing, it would be very interesting for me, and hopefully others, to learn something about the following:

 

- The signal integrity software you use, if it is not internal custom stuff;

 

- Ditto for the signal integrity verification measurements you perform, and the equipment you use to do it;

 

- The more significant sorts of things you are thinking about when you mention "proper signal integrity engineering."

[Jud]

21 minutes ago, jabbr said:

One solution is to alter buffer size, another is to track down and eliminate buffer size dependency

 

The following example from John Swenson (in an old Computer Audio Asylum thread) talks about altering buffer size and its effects (long, but I think worthwhile):
 

Quote

 

the issue is...about "how can different programms that all send the same bits to the DAC sound different?"

* * *

 

The insight is to note that in my previous post I was talking about things that affect the sound that are NOT changes to the bits, but things like ground plane noise. I was trying to show that what is happening inside the computer (processor, memory acceses etc) can change the ground plane noise. Not just the amplitude but also the spectrum of the noise. I'll give some specific examples later.

 

Not all programs that read files and send bits to a DAC do it exactly the same way. Some may have several buffers the data goes throuigh on it's path, some may only have one or two. Some may be built using a "layered" hierachical approach with different software "modules" that call each other, where others may be fairly "flat" with just one routine that does all the processing.

 

The exact sequence of instructions and memory accesses is guaranteed to be different between the programs. Since it is these instructions and memory accesses that cause the ground plane noise, I hope you can see that differences in how a task is done can produce different noise.

 

And BTW this CAN be measured. I've built a little ground noise analyzer that can easily see the difference in the noise from different programs doing supposedly the same thing.

 

Now for a concrete example. Let's take a simple program that is just coppying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the opperation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand).

 

So lets take this program and make two copies, one which has a small buffer and one which has a large buffer. The total amount of processing is exactly the same, the code is exactly the same, but is the ground plane noise the same? NO!

 

In the case of the small buffer the first thread spends a fairly short period of time waiting since the buffer empties out quickly. It spends a small amount of work often. With the large buffer each time it wakes up it has to handle a lot more data, but it waits a much longer time between sessions.

 

So why does this matter? If you look at the "work performed by the thread" over time the large buffer version shows a very "bursty" activity, but the small buffer shows a much more uniform activity. If you look at this in the frequency domain the small buffer version is dominated by relatively low intensity at high frequencies, mostly above the human hearing range. But when you look at the large buffer version you see higher intensity at much lower frequencies that are right smack dab in the middle of the human hearing range. This latter noise is going to have a much bigger affect on audibility.

 

And note this was exactly the same code, just different buffer sizes. Think what can happen when you are comparing different programs that use very different program architectures.

 

 

[Jud]

1 hour ago, marce said:

What is required is the correct rise time for the circuitry being driven, with minimal ringing... 

 

People do sometimes forget to pay attention to this stuff on the analog/component side while they concentrate on the digital/software-firmware side.  I see the same in a focus on digital filters, while the effect of analog filters like speaker crossovers, for example, tends to be ignored.

[Jud]

Just now, jabbr said:

haha well there have been numerous discussions about how USB cables sound but this could be the first which discusses an actual mechanism by which cable design might affect improve SI -- kudos to @PeterSt 

 

I don't think decreasing the slope of the transition aka transition time is outside of the USB spec, so moreover a physical change in a cable which is within spec and changes SI -- this could be historic  

 

@PeterSt didn’t confirm that it was within spec, necessarily, did he?  Or did I miss it?

[Jud]

17 minutes ago, pkane2001 said:

 

Either there's something wrong with your system, or my system is just significantly better   I've been using stock and modified $4 USB cables, and my system sounds not just musical, but the best it's sounded in over 20 years.  Zero musicality and totally boring is definitely not the way I would describe the sound I hear. Involving, enveloping, natural-sounding, wide and deep soundstage, engaging, musical. While I can imagine that Lush might make a difference (based on some of the proposed theories and mechanisms that have been discussed in this thread), I seriously cannot imagine anything but a small, incremental improvement to what I'm hearing now. Maybe I just lack imagination

 

I’ve never heard the Clairixa or Lush.  Best subjectively for me so far is the UpTone USPCB (small adapter, not cable), which if I understand correctly is not yet available separately, but is planned to be, at a price under $40.

[Jud]

12 minutes ago, pkane2001 said:

a low-pass filter. Is there a reason not to filter out most of the higher harmonics and get closer to a pure sinewave shape for each pulse?

 

Does the low pass filter have its own ringing, or is that true only of digital filters?

[Jud]

6 minutes ago, PeterSt said:

 

Analog just the same.

 

Weren't you the one referring to loudspeakers ringing just the same ? I could be wrong. 

Anyway it would be because of the filters (IIR).

 

Hi Peter.  No, not ringing (speakers are going to “ring” because it’s impossible for them not to, at least with current technology).  When talking about filters in crossovers I meant the effect of phase on timing and thus localization/imaging, so group delay and dispersion rather than ringing.

[Jud]

1 minute ago, jabbr said:

rather the digital carrier of the analog signal ... 

 

I’m accustomed to thinking of it the other way round.

[Jud]

3 minutes ago, pkane2001 said:

 

 

It's analog signal carrying digital carrier for another analog signal

 

 

 

[Jud]

13 minutes ago, PeterSt said:

OK Jud.

 

That sounds like a raised eyebrow. 

 

I think that I like minimum phase filtering less in my system, because it sounds to me like the imaging and localization aren't quite as good.  I could of course be imagining this, or if I'm not, the cause could certainly be something other than phase effects.

[Jud]

2 hours ago, manisandher said:

Hmm... So our Lushes will become obsolete? 

 

Mani.

 

Hopefully!

[Jud]

2 hours ago, marce said:

I worked on a real time network as part of a  many many years ago... it eventually matured into a used industrial bus...

Look at what a phy does...

Then start to work out your protocol, your voltage levels, current, design the transceivers, write the firmware, write the software, write the protocols, write device drivers, test it, test it again... etc. etc. Takes a team a long time just to come up with a basic working interface.

 

Probably a working Ethernet interface at the resolutions many people like to run is not terribly far off.  I'm sure it will have its own problems, and people will say, years from now, "Why do we use the Ethernet interface instead of good old USB?", the same way they talk about SPDIF interfaces today.

 

BTW, while I didn't have Peter's DAC, I did have the card he used, the very nice Juli@.  Eventually sold it, because it didn't work with FreeBSD, which I was running a lot at the time.

[Jud]

1 hour ago, plissken said:

 

Hi Jud.

 

How can this be taken in a vacuum of all the other processes that go on in a computer? Do you have direct link? Does John provide any output from the DAC measurements showing the analog is affected?

 

John was speaking of an illustrative hypothetical example:

 

Quote

Now for a concrete example. Let's take a simple program that is just coppying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the opperation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand).

 

I doubt he would have made actual measurements of a hypothetical example. 

 

1 hour ago, plissken said:

 

If you are a Windows or Linux user go into either PowerShell or Terminal and issue a PS command:

 

Powershell: ps | out-file -filepath c:\users\winlogonnamehere\documents\ps.csv

 

Take a look at your output. My system has 197 processes running on it and that's my work-a-day. I just did a clean Win10 Pro box and there are 138 processes.

 

Caching is such an integral part of OS's and you can measure this with built in reporting:

 

 

 

The above is all going on the fresh install.

 

 

Beyond noise, what might conceivably be relevant is whether the program's power draw is essentially random with regard to the music playback, or is correlated with it.  See http://www.amr-audio.co.uk/large_image/MAC OSX audio players & Integer Mode.pdf