Open-source USB interface: Audio Widget

[alexlee188]

Hi all,

So, what we want to achieve for a future version of audio-widget are:

1. Minimization of PC noise from getting to the DAC, MCLK and other important analog parts of the widget through common mode or other effects;

2. Breaking of any ground loop effect;

3. Other noise reduction strategies.

We have so far one specific proposal, ie optoisolation of MCLK (DAC to uC) and I2S signals (uC to DAC) with possible pulse shaping with flipflops (which itself may generate noise, especially on the power rails).

How do the discussions on common mode, transformers, differential input/output etc. above translate into a specific design? Any block diagram or rough schematics?

On the issue of USB-I2S-DAC vs other possibilities:

1. Looks like there is consensus that Firewire is not worth implementing as it does not have overwhelming advantage over USB given the complexity of design. Also my question is whether there are "standard" Firewire drivers for rate feedback (other than from Mac OSX).

2. No one has answered my question about "standard" Ethernet audio drivers with rate feedback yet. We are actually very interested in the possibility of an eth-widget equivalent of USB-widget. But there is no clarity on standard drivers.

3. As discussed previously, we are not keen on SPDIF or HDMI unless there is a standard way to implement rate feedback.

Alex

[borges]

Hi Alex,

thanks for summing things up!

I'd like to add:

4. Understand more about how to implement the same UAC2 support Linux offers on Windows platforms.

Regarding isolators, one option is to make a board which sits between the USB-I2S module and the Analog Board. Isolators for outgoing signals (DAC I2S) would have to be powered by the "analog" power stemming from a battery and/or wall wart. Isolators for incoming (MCLK) will run off "digital" power like the module itself, i.e. USB VBUS.

Flip-flops for buffering can be added to the layout with the option of bypassing them with a 0R resistor. I agree that we should only buffer what's needed and not waste supply noise where rise/hold times are within spec.

I can voluntare to put together a schematic for the optos.

Any takers on the analog power supply?

Børge

Originally Posted by alexlee188

Hi all,

So, what we want to achieve for a future version of audio-widget are:

1. Minimization of PC noise from getting to the DAC, MCLK and other important analog parts of the widget through common mode or other effects;

2. Breaking of any ground loop effect;

3. Other noise reduction strategies.

We have so far one specific proposal, ie optoisolation of MCLK (DAC to uC) and I2S signals (uC to DAC) with possible pulse shaping with flipflops (which itself may generate noise, especially on the power rails).

How do the discussions on common mode, transformers, differential input/output etc. above translate into a specific design? Any block diagram or rough schematics?

On the issue of USB-I2S-DAC vs other possibilities:

1. Looks like there is consensus that Firewire is not worth implementing as it does not have overwhelming advantage over USB given the complexity of design. Also my question is whether there are "standard" Firewire drivers for rate feedback (other than from Mac OSX).

2. No one has answered my question about "standard" Ethernet audio drivers with rate feedback yet. We are actually very interested in the possibility of an eth-widget equivalent of USB-widget. But there is no clarity on standard drivers.

3. As discussed previously, we are not keen on SPDIF or HDMI unless there is a standard way to implement rate feedback.

Alex

[necromia]

One suggestion is to use USB isolator circuits.
(E.g ADUM4160 | Full/Low Speed USB Digital Isolator | Digital Isolators | Interface | Analog Devices)

Make a good layout and use the PC USB supply for one side and one "pure" voltage for the other side and the result is very good.

[necromia]

Using usb isolators is also an option. (E.g ADUM4160 | Full/Low Speed USB Digital Isolator | Digital Isolators | Interface | Analog Devices)

Good layout, using PC supply for the PC side and a "pure" voltage for the receiver give good results.

[rsdio]

Originally Posted by alexlee188

No one has answered my question about "standard" Ethernet audio drivers with rate feedback yet. We are actually very interested in the possibility of an eth-widget equivalent of USB-widget. But there is no clarity on standard drivers.

I think this is one of those questions where someone could give a definitive "yes" if they know of a driver, but it's hard to give a definitive "no" just because there might be an unknown driver.

I do know that the CoreAudio system on OSX is designed to make it possible for a custom driver to integrate rate feedback no matter how the hardware presents the information. So, it seems possible that someone could write an ethernet audio driver for CoreAudio and then it would work with any enx-widget, provided that the feedback follows the same protocol. That's basically the long way of saying that I don't know of anything existing, but it wouldn't be that difficult to create a standard. Such a driver would allow CoreAudio software to SRC match to adapt to the hardware rate, or to flow-control the data source to avoid SRC, either way it would be the audio program in control of which method is used, with the driver just providing the rate information.

[alexlee188]

Hi necromia,

We need HIGH speed :-)

Alex

[alexlee188]

Hi rsdio,

That's the problem for Ethernet audio. Who are going to write the drivers for Linux and Windows? How are you going to get the music playback software to support the "standard" you have created for rare feedback? There will be folks who want their favorite player to work.

For USB, with uac1 and uac2, Foobar, vlc, media monkey, mpd etc all work out of the box :-)

Alex

[rsdio]

Originally Posted by alexlee188

Hi rsdio,

That's the problem for Ethernet audio. Who are going to write the drivers for Linux and Windows?

Those systems don't have pull-model audio standards anyway, at least not so far as I am aware. I made it clear that I was talking about CoreAudio only.

How are you going to get the music playback software to support the "standard" you have created for rare feedback? There will be folks who want their favorite player to work.

Well, all of the music software on Mac OS X would immediately work. That's the beauty of CoreAudio: they have already trained the audio software developers to work within a pull-model, so now all new rate feedback hardware will automatically work. Meanwhile, developers who are trying to port existing Windows and Linux audio software to OSX are whining that CoreAudio doesn't support their legacy push-model code base.

I have little hope for Windows, but it seems like someone should develop a CoreAudio-like system for Linux. PortAudio is still push-model (again, just my understanding).

[abraxalito]

Originally Posted by alexlee188

How do the discussions on common mode, transformers, differential input/output etc. above translate into a specific design?

For the design to be of the lowest noise the ground currents on/off the boards in the system need to be minimized as far as possible. This in practice means using differential signalling (suggest LVDS) for all interfaces except the very low speed ones (like status LEDs).

Do you know if Atmel offer any device where the USB high-speed PHY can be a separate part? That might allow Demian's point about radiated noise to be taken on board by minimizing the area of circuit able to act as antenna. Otherwise the whole MCU board has the potential to be an EMI aggressor

@borges - you asked about analog power supply. That to be designed without picking a DAC chip first?

[Turbon]

Originally Posted by abraxalito

...

@borges - you asked about analog power supply. That to be designed without picking a DAC chip first?

What about those Salas ones, they seem to be quite popular. Not that I have used one myself. Then we have the Sjöström Super Regulators by peranders as well - they can do from 2.5V to over 30V. So the should fit to whaterver DAC that is choosen.

Brgds