USB audio cracked... finally!

[semente]

1 hour ago, PeterSt said:

 

Ehm ... Which one would that be ? (somehow I am getting anxious)

 

Don't worry, it's not yours.

It's not a commercially available DAC.

[PeterSt]

@semente

[semente]

2 minutes ago, PeterSt said:

@semente

 

[Jud]

6 hours ago, PeterSt said:

 

but it is always (spiky) current draw which causes noise (this was dealt with more in the beginning of the thread but now for the receiver's end).

 

 

5 hours ago, pkane2001 said:

 

All shift registers, all memory load/refresh/read operations, all FPGA logic, etc., all generate a constant level of noise at the ground plane.

 

 

OK, I'm going to do more guessing without really knowing anything, so if I'm talking about "six impossible things before breakfast," please be gentle. 

 

What must always go through are the bits, right?  So let's isolate well from all the noise and let only the bits go through.

 

Now the (electrical pulses that are the analog representation of the digital) signal hits the buffer and clock circuitry.  And this must go through, because it is the signal, the "bits."  I remember a white paper where ESS bragged that in its chips, noise was -140dB.  140dB down from what?  The signal, of course.

 

Now as marce has taught me (thank you), as long as the analog electrical pulses that represent the digital signal are *regular*, they can be as square or as sine as you like.  Let us say that if you would like to cause the least electrical disturbance as these analog electrical pulses hit the buffer and clock circuitry (a disturbance that will be nicely correlated with your signal), you might wish to make these pulses more sine than square.

 

So how would you do that?  Well, you'd low-pass filter out the higher frequencies of the square waves.

 

What properties of a cable would you adjust (capacitance, resistance, etc. - would skin effect play any role if we've got 12-24mHz rates running across the cable, or not until we reach frequencies much higher than that?) in order to do that filtering?  Or would it be easier just to put an analog filter with quite small components somewhere along the cable?

[mmerrill99]

7 hours ago, pkane2001 said:

 

Ah, yes, I did read it, thank you for the reminder. 

 

The point is not that jitter cannot occur in USB transmission. The point is that jitter on USB side has zero effect on jitter on the I2S side using isochronous protocol. How ever the bits arrive on the receiver side, they are ultimately stored in a memory buffer and doled out from that buffer using an onboard clock that is not subject to jitter errors on the receiver side of the buffer. As long as timing errors are not so large as to cause an entire microframe to be dropped (resulting in a huge number of bit errors), jitter on the receiver side does not translate into jitter on the I2S side. 

Sorry, but that's incorrect

 

How big do you think the buffer is?

If it was big enough to be able to store all the transmission of a track & all USB processing was shut down until the buffer was emptied, then your view would have some value but that is not the way any USB buffer works.

 

In other words while data is being output from the buffer, USB data is also being read  - the clock(s) that are timing the I2S output are likely being affected by the concurrent noise being generated within the system

 

This has been repeated over & over again in this & other threads - does it need stating on every page?

[mmerrill99]

10 minutes ago, Jud said:

would skin effect play any role if we've got 12-24mHz rates running across the cable, or not until we reach frequencies much higher than that?) in order to do that filtering?

To transmit a 480MHz square wave (the USB high speed signal) a USB cable needs to be able to pass undistorted, up to the 5th harmonic of this signal i.e 2GHz of bandwidth needed - so yes, skin effect can play a role

[mmerrill99]

If anybody read Jabbr's links, you would see that to control the overshoot ringing can be as simple a matter as using a larger termination capacitor than the 45ohm spec of the USB standard - in Fig 16 of the Micron paper, 90ohms is simulated to almost eliminate the ringing i.e the rise time is slowed down

 

Now, as some here constantly state - if interpreting the bits correctly is not affected by this risetime slowdown, then the digital signal is arriving unperturbed but the electrical noise caused by signal overshoot is diminished so we have a net gain.

[mmerrill99]

6 hours ago, pkane2001 said:

 

Are you sure that tiny variations in timing will result in a detectable difference in analog domain? Remember, all digital circuits produce noise. All shift registers, all memory load/refresh/read operations, all FPGA logic, etc., all generate a constant level of noise at the ground plane. The sequence of these noise generating events is the same (or very, very nearly the same) with or without jitter in the same circuit. The only thing that changes is their timing if jitter is present.

 

Are you really ready to say that time differences at the level of a few hundred picoseconds in processing incoming bits will alter all that computation noise sufficiently to suddenly make an audible difference? I'd love to see a model that shows that. You'll also need to show this for more than one implementation, as @Speed Racer is suggesting, since different designs will generate wildly varying computation noise and have very different reaction to incoming jitter.

Again, I have to say that I believe this is wrong.

 

Self-noise generated within shift regs, FPGAs, etc do NOT "generate a constant level of noise at the ground plane" - the noise mirrors the processing & if this is a routine regular signal being processed then the noise will have this characteristic i.e noise will be deterministic.

 

How do you know what the level of this noise is? Where do you get a few hundred picoseconds of jitter?

 

You were asked a number of questions by Jabbr but instead of answering these questions you made further unfounded assumptions

6 hours ago, jabbr said:

how do you know that the assumptions are correct? Do you have detailed knowledge of the state of the ground and power planes? Circuit? Do the onboard clocks share common power/ground? Does this have an effect? Are you sure? Have you made a detailed model of the entire circuit? Is the model accurate?

 

[Narcissus]

4 hours ago, manisandher said:

These chips are cheap, but getting hold of 16 BG N caps (two per chip) won't be easy or cheap now. I'm sure there are loads of alternatives though.)

 

BG's considered the holy grail of caps, you might find some if you're lucky and know where to look for em.

 

Elna Silmic II might be the cheaper alternative.

[marce]

33 minutes ago, mmerrill99 said:

To transmit a 480MHz square wave (the USB high speed signal) a USB cable needs to be able to pass undistorted, up to the 5th harmonic of this signal i.e 2GHz of bandwidth needed - so yes, skin effect can play a role

The bandwidth is determined by the signal rise time, not the ultimate clock frequency:

Fknee=0.35/Tr where Tr is the 10-90% rise time in ns

[pkane2001]

32 minutes ago, Jud said:

So how would you do that?  Well, you'd low-pass filter out the higher frequencies of the square waves.

 

What properties of a cable would you adjust (capacitance, resistance, etc. - would skin effect play any role if we've got 12-24mHz rates running across the cable, or not until we reach frequencies much higher than that?) in order to do that filtering?  Or would it be easier just to put an analog filter with quite small components somewhere along the cable?

 

Hi Jud,

 

That's exactly what I said earlier in this thread: low pass filtering can remove some HF noise and harmonics. This I can understand. What I don't understand is how noise generated by jitter can rise above the level of noise generated by all the digital circuits doing complex digital processing on these bits. That noise is always there, and I would suspect is many orders of magnitude greater than noise generated by jitter. If this constant noise is properly handled in the receiver circuit, then the tiny addition of jitter will be handled as well. And if not handled or poorly handled, the tiny addition of jitter to the loud cacophony of computing noise will be insignificant. 

[jabbr]

6 hours ago, pkane2001 said:

Are you sure that tiny variations in timing will result in a detectable difference in analog domain?

By definition if there is a difference, it is measurable in the analog domain given sufficient resolution in the measurement equipment -- well at least until we get into quantum level/Heisenberg levels (was that the trick to the question ?

 

6 hours ago, pkane2001 said:

 

Remember, all digital circuits produce noise. All shift registers, all memory load/refresh/read operations, all FPGA logic, etc., all generate a constant level of noise at the ground plane. The sequence of these noise generating events is the same (or very, very nearly the same) with or without jitter in the same circuit.

Actually the sequence depends also on the software, branch logic etc. 

6 hours ago, pkane2001 said:

 The only thing that changes is their timing if jitter is present.

No, in the analog domain, the shape of the digital bits is different. An "eye pattern" gives a rough measure of the degree to which the shapes differ on cycle to cycle basis. Remember that ultimately all digital circuits are comprised of little itty bitty transistors  

[mansr]

9 minutes ago, marce said:

The bandwidth is determined by the signal rise time, not the ultimate clock frequency:

Fknee=0.35/Tr where Tr is the 10-90% rise time in ns

The rise time for high-speed USB2.0 being 500 ps.

[mmerrill99]

13 minutes ago, pkane2001 said:

 

Hi Jud,

 

That's exactly what I said earlier in this thread: low pass filtering can remove some HF noise and harmonics. This I can understand. What I don't understand is how noise generated by jitter can rise above the level of noise generated by all the digital circuits doing complex digital processing on these bits. That noise is always there, and I would suspect is many orders of magnitude greater than noise generated by jitter. If this constant noise is properly handled in the receiver circuit, then the tiny addition of jitter will be handled as well. And if not handled or poorly handled, the tiny addition of jitter to the loud cacophony of computing noise will be insignificant. 

You constantly talk about jitter why do you ignore what's being said about ringing & the noise it can generate?

You seem to ignore the deterministic nature of this ringing & hence the resultant noise?

You have been asked many times about your assumptions but not yet answered any of these questions

[pkane2001]

 

59 minutes ago, mmerrill99 said:

Sorry, but that's incorrect

You base this on actual knowledge or just guessing?

 

Buffer size is usually two to three microframes. Microframe size is controlled by the receiver circuit based on available buffer space and timing.

[PeterSt]

20 minutes ago, Narcissus said:

BG's considered the holy grail of caps, you might find some if you're lucky and know where to look for em.

 

A funny thing is that we could not find real proof of that - only the opposite. People often upgrade their NOS1 with them (in all sorts of places I might add) and as often those DACs measure considerably worse. So mind you, this is thus even measurable, while most is not at all. So it must make a real difference, somewhere. And then to think that we originally use :

 

22 minutes ago, Narcissus said:

Elna Silmic II might be the cheaper alternative.

 

[pkane2001]

Just now, mmerrill99 said:

You constantly talk about jitter why do you ignore what's being said about ringing & the noise it can generate?

I thought that's exactly what I've been talking about -- noise generated by incoming jitter. I suggest you go back and read what I actually said. 

[mmerrill99]

1 minute ago, pkane2001 said:

 

You base this on actual knowledge or just guessing?

 

Buffer size is usually two to three microframes. Microframe size is controlled by the receiver circuit based on available buffer space and timing.

Are you suggesting that buffer size is large enough to be able to store a full track & all processing closed down while the buffer is being emptied?

If not then there is concurrent processing of USB data (& buffer filling) while data is being timed out of the buffer i.e there is noise being generated while buffer is being read.

Does this support your contention that the audio clocks timing the buffer output are immune?

 

If you disagree with this,please make a logical answer that addresses the points rather than another question!

 

[mmerrill99]

2 minutes ago, pkane2001 said:

I thought that's exactly what I've been talking about -- noise generated by incoming jitter. I suggest you go back and read what I actually said. 

That's my point - you are so focused on incoming jitter that you are ignoring what is being said - the overshoot of the signal at the USB receiver chip - this is NOT jitter, it's a totally different mechanism

 

I suggest you read what is actually being said in  this thread!

[Jud]

1 minute ago, pkane2001 said:

I thought that's exactly what I've been talking about -- noise generated by incoming jitter. I suggest you go back and read what I actually said. 

 

Hi Paul -

 

I was speculating it would be incoming *signal* generating noise and thus jitter *at the clock and buffer circuitry*, if that, or the fact that it's signal-correlated, would make any difference.

[mmerrill99]

4 minutes ago, Jud said:

 

Hi Paul -

 

I was speculating it would be incoming *signal* generating noise and thus jitter *at the clock and buffer circuitry*, if that, or the fact that it's signal-correlated, would make any difference.

Signal correlated noise is a very different beast to random noise - so yes, I would say it "would make a difference"

[mmerrill99]

One could look on this thread as an analog for USB signal noise - at regular intervals a stream of posts generate noise, then there is a lull & again another stream of posts arise which ignore all that went before

 

This is deterministic noise

[PeterSt]

26 minutes ago, mmerrill99 said:

Self-noise generated within shift regs, FPGAs, etc do NOT "generate a constant level of noise at the ground plane" - the noise mirrors the processing & if this is a routine regular signal being processed then the noise will have this characteristic i.e noise will be deterministic.

 

I think that many people may have a hard time grasping what "noise" actually is and what its source is. Now let me try to explain it like this (it is a large detour beyond the real subject but it may help) :

 

USB is packeted. The contents of a packet is not known in advance; It is determined by the operating system, even on ad-hoc basis.

The receipt / reception of the packet(s) in the in-DAC USB receiver, requires the current needed to receive one burst of bits, implied by the packet size. This means :

a. that the current required is always changing and that a not really random pattern implies an SQ flavor;

b. it even depends on the music data itself, because the sequence of 1's vs 0's imply different current spikes.

 

Ad b. : I could show you the data correlated jitter of this, when no galvanic isolation would be in i2s. So this part is solved by that isolation ? maybe because my gear can not measure better than 3ps(p-p). Thus maybe not. 

 

If this is understood (and accepted) you could be ready for me showing you the capture by microphone of music sounding through i2s alone. So mind you, that too is noise. But it is highly correlated to what comes from it after the D/A conversion (analogue signal). So we have all kind of 010010000100010100100001 digital data, and it really produces music. One thing : it must be attenuated by 136dBFS to sound the loudest and the best to music because then all bits will be zero except for the least significant bit. Call it the complement of super dither.

And of course it is a D/A converter without D/A conversion.

This is thus noise which is caused just by the changing one one bit and you will be able to hear the real music of it through the speaker. You can of course figure that in reality this implies distortion. Plus, when all of the bits play (no digital attenuation) it will be quite messy.

[PeterSt]

20 minutes ago, pkane2001 said:

I thought that's exactly what I've been talking about -- noise generated by incoming jitter. I suggest you go back and read what I actually said.

 

I only read this after my previous post, and now I am sorry I included a text about jitter in it. So of you skip that part and only read the "i2s music" part you are where I and Merrill want you to be.

Also keep in mind, that in my first posts in this thread I have been repeatedly (kind of) claiming that I regard jitter in USB about completely irrelevant. But still a little about that in a next post.

[mansr]

18 minutes ago, mmerrill99 said:

That's my point - you are so focused on incoming jitter that you are ignoring what is being said - the overshoot of the signal at the USB receiver chip - this is NOT jitter, it's a totally different mechanism

Is this supposed overshoot real? I don't see it in any of the scope screenshots usually trotted out when promoting USB decrapification widgets.