Open-source USB interface: Audio Widget

[alexlee188]

The USB-I2S module is based on the Atmel AT32UC3A3 microcontroller. The theoretical limit of the transfer at the I2S side is 32 bit 250 khz full duplex stereo. As Borge & George mentioned, we have working hardware/firmware running 24bit 192khz stereo full duplex now.

The limitation is not at the USB side, as there is still headroom to grow under uac2.

For high transfer rate/bit depth and multichannel work, we will need to implement an FPGA to provide multiple I2S or TDM connections to the DAC. We may need to change the uController to an ARM Cortex type as well.

However, our current focus is to get the 24bit 44.1-->192khz stereo working well. We have found that there are very few (if any) source music at more than 24 bit depth. We have also found that by having bit perfect transfer at the sampling rate of the source music to the DAC, and clocking the DAC (ES9023) at the native sampling rate with low jitter XO ( < 1 ps vs about 200ps for SPDIF), the sound quality is excellent.

We are conducting audio characterization of our prototype boards (the AB-1 and a single board USB9023) this week and hopefully we will have some lab measurement results soon.

Alex

[UnixMan]

Originally Posted by alexlee188

The theoretical limit of the transfer at the I2S side is 32 bit 250 khz full duplex stereo.

is this limitation due to the chosen uC capabilities? I mean, how do they managed to play 384KHz/32bit "DXD" streams on the Buffalo II?

[borges]

Hi Paolo,

We have looked at various FPGA + USB phy solutions. The most interesting solution in my opinion is to use an intelligent phy with endpoint buffers and a parallel FIFO interface to the FPGA. This would require porting the current USB code to a different platform, or using something in the FPGA which can be programmed in C. I've done I2S in Verilog on Xilinx, but no C programming for FPGA platforms.

I know that as a proper geek I should never ask _why_ only _how_ If there is source material which is properly recorded, I say let's do what it takes to get it out. But if the issue is to take source material < 32/384 and upsample it before USB transferral and DA conversion, I'd rather put my faith into the digital filters of the DAC.

Which is what I have done. I have a CD player where an FPGA accepts I2S, does fully custom upsampling and filtering before sending the signal off to the DAC. This is the system where the SRC4392 used to be.

Børge

[mace1337]

Thanks for the insight Alex and Borges. 24/192 will be more than enough for my purposes.

BTW: This is probably way too early into the project but have you thought about implementing multichannel? Like 5x 24/96? (These kinds of files have been available for some time)

[alexlee188]

---------- Forwarded message ----------
From: Børge Strand-Bergesen <borge.str...@gmail.com>
Date: Feb 26, 4:08*pm
Subject: Project goals
To: Audio-Widget


Hi Gaston,

> 1a) What are the throughput limitations? I would sort of expect something
> like 66 MHz / 192 kHz / 30 bits per sample comes out as 11 channels - some
> overhead so maybe 8 channels?

Well, there's also the question of what you want to use and what the
various data sources can feed. Alex knows more about the throughput of
the device. We have contemplated using anFPGA(seen by MCU as DMA
mapped external standard RAM) which does I2S serializing for
multi-channel. But that is well into the future.

> 1b) Could there be any case where simultaneously utilizing SPI and I2S would
> be beneficial or is the bottleneck elsewhere?

What would the SPI do? In my experience there is precious little audio
equipment for SPI (which is a shame, really). But the USB-I2S module
at least has pins for a hardware SPI interface. They might form a link
to anFPGAor just be a plain old control bus.

> 2) Will the boards from SDR-widget be compatible?

Physically pin-by-pin: No. The USB-I2S module is given a small
footprint with only essential audiophile USB functions. Firmware-wise:
I'm personally hoping Roger's efforts will be flexible enough that a
small number of config settings can target the code for one device or
the other.

> 3) What was the reason for not going the XMOS path?

I've not been involved in the sdr-widget MCU discussion. But try
finding open-source firmware and public forums for XMOS, and things
become fairly obvious.

> 4) Where do I sign up to join the fun?

Looks like you just did! Where do you want to chip in?

There's hardware design (1st generation of USB-I2S module and AB-1
were just ordered, fancier analog boards would be cool), debugging the
USB-I2S module from a firmware standpoint, general firmware
unification etc. The one big thing lacking is a Windows driver for
UAC2. That is somewhat of a tall order, though.

Cheers,
Børge

[tdtsai]

Hi George:
Its very interesting. If I write Windows Driver for this project, does I need to open my source code? It should not very difficult to develop a WDM Audio driver to this device. Please email me or send message to me with your device's descriptor. I can start to develop Windows driver.

Originally Posted by GeorgeBoudreau

Hi Demian,

The unified firmware supports both UAC1 + UAC2 switchable via an external WidgetControl GUI tool. The firmware works with Linux 2.6.38 and Mac OSX. Auto sampling rate switching with compatible software eg Music Player Daemon.

We are working on: async out with rate feedback under Windows, UAC2 under Windows will require a driver.. Aany bored Windows driver developers looking for an open-source challenge?

The unified firmware supports both DAC boards (and future boards) selectable with GUI WidgetControl tool.

Regards,
George Boudreau

[GeorgeBoudreau]

Hi tdtsai

All the firmware is available online from this github
https://github.com/amontefusco/sdr-widget

I am not a lawyer so the following comment could be retracted.

If you choose not to release your source code that is up to you. It would be nice if you contributed your work to the open-source community but not a requirement. If you could create an open source UAC2 driver for Windows your name would be spoken with reverence for years to come

The USB/I2S/DAC project was created so the DIY fan would not be tied to specific hardware or software. The firmware if available and those wanting to port the code to another processor are free to do so.

George

Originally Posted by tdtsai

Hi George:
Its very interesting. If I write Windows Driver for this project, does I need to open my source code? It should not very difficult to develop a WDM Audio driver to this device. Please email me or send message to me with your device's descriptor. I can start to develop Windows driver.

[alexlee188]

The relevant github branch is :

sdr-widget-2-dib

George: maybe u can do an lsusb -v dump of the uac2_audio image so that tdtsai can have a rough idea of the descriptors ?

Alex

[borges]

Originally Posted by tdtsai

Hi George:
Its very interesting. If I write Windows Driver for this project, does I need to open my source code? It should not very difficult to develop a WDM Audio driver to this device. Please email me or send message to me with your device's descriptor. I can start to develop Windows driver.

Hi Tdtsai,

In my opinion: NO, you don't need to open that source. But it would be nice :-)

The audio-widget and sdr-widget projects are an open-source implementation of the Device side of USB Audio Class 2. The Windows driver would become the Host side implementation of UAC2.

There are open-source drivers for Linux. The ALSA project might be a place to start: Main Page - AlsaProject Other members of the group know more than me about the Host side implementation. Obviously, if you reuse open-source code its license will say what you must do in terms of opening derived works.

Regardless of your choice to open-source or not, I'll be happy to help test your efforts. But if you choose to open-source it, I'm pretty sure you will attract a larger crowd and co-contributors. I have thought quite a bit about the user interface and capabilities a driver should provide. But my Windows programming experience is far too limited for me to start on such an adventure. So I design boards instead!

Cheers,
Børge

[tdtsai]

Hi Cheers
I am driver developer in C-Media Inc. So I can't open source code. Because those code belong to my company. Basically I can add support this device in our driver. If your device is a standard UAC2.0 device, our driver can support it very easy. I will check the descriptor first. Thanks.

BR,
Tzung-Dar Tsai

Originally Posted by borges

Hi Tdtsai,

In my opinion: NO, you don't need to open that source. But it would be nice :-)

The audio-widget and sdr-widget projects are an open-source implementation of the Device side of USB Audio Class 2. The Windows driver would become the Host side implementation of UAC2.

There are open-source drivers for Linux. The ALSA project might be a place to start: Main Page - AlsaProject Other members of the group know more than me about the Host side implementation. Obviously, if you reuse open-source code its license will say what you must do in terms of opening derived works.

Regardless of your choice to open-source or not, I'll be happy to help test your efforts. But if you choose to open-source it, I'm pretty sure you will attract a larger crowd and co-contributors. I have thought quite a bit about the user interface and capabilities a driver should provide. But my Windows programming experience is far too limited for me to start on such an adventure. So I design boards instead!

Cheers,
Børge