Open-source USB interface: Audio Widget

Vbus is a sense pin fir the uC and had to havr +5V for USB enumeration. It has to be referenced to uC ground. D+/D- are differential but they have to be referenced to USB ground.

So what you propose to do looks likr it will not work.

Options fir USB isolation arr
1. isolated USB hub - makr surr it is USB high speed.
2. Opto isolation of i2s and MCLK.

Alex
Alex thanks for your reply. As a matter of fact, I took the plunge before you wrote it.
My external 5V supply is connected to pin 2 of J5. Bridging pin1 and 2 of J5,
feeds the VBUS from the 5V external supply. I then removed L1006, L1007 and C1075, thus isolating the VBUS and ground lines from the USB connector.
The UC ground is unchanged (I had verified that it was connected to digital ground on the PCB), but is now floating relative to the computer ground.

It works and I would say it improves the sound by no small margin.

I got the idea from here.
 
Last edited:
Hi Giulio,

Great that it works. With USB (and thus PC) isolation the SQ should improve, as noise conducted from PC power and ground is a major problem.

So the differential USB D+/D- can be uaed by the uC though it is floating relative ti uC gound.

I'm still concerned though with static damage to the uC pins.

Maybe a back ti back diode connection across the USB ground and uC ground will offer some protection

Alex
 
Hi Alex,

excuse my ingnorance. I am not sure I understand your statement below.

So the differential USB D+/D- can be uaed by the uC though it is floating relative ti uC gound.

I'm still concerned though with static damage to the uC pins.

uC ground is connected to digital ground on the pcb. I checked it before going ahead with the mod. From the schematic, do not ESD001 and ESD002 (tying USB D+/D- to ground) provide protection again static damage? Are you saying that USB D+/D- are referenced to ground in the PC but not on the AB1.1?
I am also confused: are differential lines ever referenced to ground? They are not in analog balanced equipment as far as I understand. But my knowledge is limited.

Many thanks
Giulio
 
Member
Joined 2004
Paid Member
Only if you don't mind frying the USB devices on each end. The connections have common mode maximums and are not able to withstand common mode voltages and currents past some modest limit. A static discharge with some energy could toast both ends, not to mention significant power leakage currents.

It may be possible to use a resistor to isolate the VBUS and still have it turn on the link. And some resistance in the ground would be tolerable but not much. However a common mode choke with sufficient inductance may work pretty well. Especially if you have a separate ground return for the PC to the preamp ground (or equivalent) so the ground current doesn't go through the audio links.
 
how about optical linkage of usb clock and data lines, over gig-e quality optical tx/rx pairs? ;)

well, I'm maybe half serious.

usb2 is less than gig-e and didn't gig-e used to run over glass fiber links at one point?

you want isolation - opto is as isolated as you can get. fool the host into thinking there's a usb device there and just relay the clock and data over light. no??
 
I admit I don't know the fine details of usb audio, but isn't there some buffering happening, so that timing at the usb level does not matter?

or, am I wrong on that?

isn't usb 'modern' audio supposed to control the flow and basically just keep its local buffer full? other than that, what else is there that the host does? the usb timing should not be related at all to audio timing. (no??)

as long as you produce data in the widget's buffer and never under-run, I'm not sure why 'jitter' matters at the usb packet level. this seems more like data networking and not audio.
 
hmm i'm not sure i'm with you. why would you even bother piping Mclk in on light if you arent going to use it? just leave it out and use something local. it has no value if its not being used, why would you reclock a clock?

The MCLK is generated close to the DAC to clock the DAC.

MCLK is divided (to a value less than 16 Mhz for the uC) and piped to the uC for the uC to work out how many samples it should obtain from the PC host (and then to be supplied via i2s to the DAC).

So it is needed :)

Back to the discussion on USB isolation:

PC <----- (A) ------> uController ----- (B) ------> DAC
|<-----(C)---- XO --->

(A) is the USB link between PC host and uController.
(B) is the i2s signals from uController to DAC
(C) is the divided MCLK from XO to uController. The XO clocks the DAC directly.

If we opto isolate (A), we cut off the noise from the PC to the DAC. However, digital noise from the uController itself will still affect the DAC.

IF we opto isolate (B) and (C), noise from PC as well as noise from the uController is reduced.

Jitter is NOT an issue in the links (A) (B) and (C).

In fact we have proposed to Borge to use optoisolation of (B) and transformer isolation of (C).

Alex
 
nevermind me, I read 'how about optical linkage of usb, (comma) clock and data lines, over gig-e quality optical tx/rx pairs?', rather than USB CLOCK and data lines

how about optical linkage of usb clock and data lines, over gig-e quality optical tx/rx pairs? ;)
so i was thinking you were saying to pipe MCLK over the light. thus why I said
why would you even bother piping Mclk in on light if you arent going to use it? just leave it out and use something local
@ Alex: of course its needed, i'm clear on how the dac clocking works. I meant (and said) why not use something local. as in why pipe clock in and reclock it if its going to be replaced with something local; just drop it and substitute your own. but that was in query of something that wasnt at all what linuxworks was saying
 
In fact we have proposed to Borge to use optoisolation of (B) and transformer isolation of (C).

... And I'm all for starting to work on that as the next project after debugging on AB-1.12.

In fact, I have a new batch of modules in the pipeline which lend themselves well to inserting a go-between board for optical isolation and analog +5V insertion.

I'm actually planning to use the module in a hi-end DAC where this kind of solution is very much desired.

Børge
 
ok, good, so I'm not crazy.

;)

I would have been upset to learn that usb bit-transfer jitter would 'matter' here. its one of the goals of the new, improved usb audio, as I kind of understood its motivation to be.

I kind of wonder what would usb have been like if it had been opto, all along, with electrical there just for remote power. i wonder why hdmi guys thought they needed so much wire when a few opto cables (one in each direction) would have been enough.
 
Member
Joined 2004
Paid Member
HDMI over optical was not going to happen as a commercial product anytime soon. 3 GHz X4 optical links are too expensive for that market. There have been at least 3 attempts by big players that all fizzled.

You can get Optical USB now, but its expensive and doesn't really solve these problems. It just moves them to a new place in the chain.
 
Please verify this for the uninitiated like me... For an external 3.3v/5v ps I do the following;

J5 - 1 : no connection
J5 - 2: +5v from external ps
J5 - 3: +3.3v from external ps
J5 - 4: ground from external ps

Remove R22/R23

Recommended by others: no cap on C15 if using external ps.

Thanks for the handholding...

You should connect your 5V supply to pin 2 and remove R26. You remove R22 if you connect a 3.3V supply to J3 for the chrystals. You remove R23 if you connect a 3.3V supply to J4 for the analog stage of the dac.

Otherwise those two supplies are derived from the 5V supply you have connected to pin 2. Connecting a 3.3v supply to pin 3 of J5 achieves nothing, since that pin is connected to the output of U1100. You would have to remove U1100. I would leave that alone.

giulio