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
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
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?
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
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
Copy of archived post at google audio-widget group
---------- 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
---------- 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
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.
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
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
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
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
Last edited:
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
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
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
Hi Mr Tsai,
Excellent news !!! You obviously has the expertise to develop the windows uac2 driver to support the audio-widget
We have full control over the widget firmware so I am positive that we can get the uac2 driver and the widget working !!!
We did a similar thing working with the Linux uac2 driver kernel developers to sort out the bugs and interpretations of uac2 and so the widget works very well under Linux kernel 2.6.37 and later.
One key issue with Win driver is that the widget currently enumerates as a composite device, with UAC, hid, and a libusb interfaces. I understand that windows may not easily allow a uac2 interface to be part of a composite USB device. If it is too difficult, we can change the widget firmware image to a single audio device, if need be.
I am traveling right now and cannot do a descripter dump for u, but George or Roger or Liftur might be able to do so
This is very exciting a development for us and it will be great fun testing out the driver during the development cycle - am anticipating many blue screen of death before we have it debugged
Alex
Excellent news !!! You obviously has the expertise to develop the windows uac2 driver to support the audio-widget
We have full control over the widget firmware so I am positive that we can get the uac2 driver and the widget working !!!
We did a similar thing working with the Linux uac2 driver kernel developers to sort out the bugs and interpretations of uac2 and so the widget works very well under Linux kernel 2.6.37 and later.
One key issue with Win driver is that the widget currently enumerates as a composite device, with UAC, hid, and a libusb interfaces. I understand that windows may not easily allow a uac2 interface to be part of a composite USB device. If it is too difficult, we can change the widget firmware image to a single audio device, if need be.
I am traveling right now and cannot do a descripter dump for u, but George or Roger or Liftur might be able to do so
This is very exciting a development for us and it will be great fun testing out the driver during the development cycle - am anticipating many blue screen of death before we have it debugged
Alex
Hi Alex:
I had check the descriptor, its seems mix UAC 1.0 and UAC 2.0. For example Feature Unit descriptor seems use UAC 1.0 format not UAC 2.0 format. And you had add 2 Clock source Unit and one Clock Selector Unit. I can't understand why you need Clock Selector Unit? And the stream format descriptor also is UAC 1.0 format. I think you have better to modify you firmware to make those descriptor more correct.
You can reference follow device's descriptor
Home Audio :: Digital to Analog Converters :: MHDT Labs USBridge USB to SPDIF converter - ALO Audio
BR,
Tzung-Dar Tsai
I had check the descriptor, its seems mix UAC 1.0 and UAC 2.0. For example Feature Unit descriptor seems use UAC 1.0 format not UAC 2.0 format. And you had add 2 Clock source Unit and one Clock Selector Unit. I can't understand why you need Clock Selector Unit? And the stream format descriptor also is UAC 1.0 format. I think you have better to modify you firmware to make those descriptor more correct.
You can reference follow device's descriptor
Home Audio :: Digital to Analog Converters :: MHDT Labs USBridge USB to SPDIF converter - ALO Audio
BR,
Tzung-Dar Tsai
Hi Mr Tsai,
Excellent news !!! You obviously has the expertise to develop the windows uac2 driver to support the audio-widget
We have full control over the widget firmware so I am positive that we can get the uac2 driver and the widget working !!!
We did a similar thing working with the Linux uac2 driver kernel developers to sort out the bugs and interpretations of uac2 and so the widget works very well under Linux kernel 2.6.37 and later.
One key issue with Win driver is that the widget currently enumerates as a composite device, with UAC, hid, and a libusb interfaces. I understand that windows may not easily allow a uac2 interface to be part of a composite USB device. If it is too difficult, we can change the widget firmware image to a single audio device, if need be.
I am traveling right now and cannot do a descripter dump for u, but George or Roger or Liftur might be able to do so
This is very exciting a development for us and it will be great fun testing out the driver during the development cycle - am anticipating many blue screen of death before we have it debugged
Alex
Hi Tsai,
The descripter dump was created with the wrong (old) version of lsusb which does not u derstand uac2. George has generated the correct uac2 dump which he will forward to u and it is also found here:
http://db.tt/SRBL4Ad
Best regards,
Alex
The descripter dump was created with the wrong (old) version of lsusb which does not u derstand uac2. George has generated the correct uac2 dump which he will forward to u and it is also found here:
http://db.tt/SRBL4Ad
Best regards,
Alex
well, yes and no.
In principle DXD is supposed to become the new standard for digital masters and eventually for end users too (although of course nobody knows whether this is really going to happen..).
To date even 24/192 source material is scarce... for DXD I'd speak of just a few "samples". But they are indeed already available (including some free downloads).
What is the purpose of the second CLOCK_SOURCE? It looks like CS4 and CS5 are supposed to correlate to 22.6MHz and 24.6MHz master clocks, but instead of using a CLOCK_MULTIPLIERs to derive the support sampling frequencies, it looks like the Clock Freq. Control and Clock Validity Control are expected to be used to configure the clock hierarchy. Is this correct?
Hi Blushift,
Not sure what you are referring to just here....
But I'll let you know about the clocking scheme for the audio:
On AB-1 we use 22.5792 to play back 44.1, 88.2 and 176.4ksps. 24.576 is for 48ksps. The ratios are 2^n. Both clocks are available on AB-1 as good XOs, so nothing passes through a PLL or any digital dividers from XO to DAC.
But the MCU can't handle clocks about 16-ish MHz, so we divide the clocks down to 11.2896 and 12.288MHz, multiplex them into the MCU and repeat the same MUX function on AB-1 using analog switches.
Since these clocks are switched, a separate always-on clock is used to drive the MCU.
Børge
Not sure what you are referring to just here....
But I'll let you know about the clocking scheme for the audio:
On AB-1 we use 22.5792 to play back 44.1, 88.2 and 176.4ksps. 24.576 is for 48ksps. The ratios are 2^n. Both clocks are available on AB-1 as good XOs, so nothing passes through a PLL or any digital dividers from XO to DAC.
But the MCU can't handle clocks about 16-ish MHz, so we divide the clocks down to 11.2896 and 12.288MHz, multiplex them into the MCU and repeat the same MUX function on AB-1 using analog switches.
Since these clocks are switched, a separate always-on clock is used to drive the MCU.
Børge
Hi Blushift,
U are correct in your interpretation of the uac2 descriptor
Uac2 is so flexible that there are many ways to skin the cat. We have been tweaking the descriptor to work with the uac2 drivers. We have been trying to make the descriptor and UAC request processing to be compatible with Mac OSX and Linux. At that point in time the Linux driver did not support clock multiplier. Even today the Linux driver clock selector/clock source is not able to parse some corner cases and we have to put in workarounds in the firmware.
So the current clock sources, one for the 44.1x sampling freq and one for the 48x freq is a good representation of the underlying hardware of two ultra low jitter XO's, as Borge has explained. This will pave the way for FUTURE drivers which can intelligently select and configure the best clock for the particular playback situation in the fly - ie without any re-sampling for bit perfect reproduction.
However, it looks like the current windows uac2 driver we are trying to interface with does not support clock selector. So we are planning to have a branch of the firmware that had only a single clock source and no clock selector. We will have a workaround such that all the 6 freq: 44.1/48/88.2/96/176.4/192 will be available and the firmware will switch the correct XO internally depending on the sampling freq set by the driver.
The descriptor will evolve as the driver/
Firmware get more aophisticated.
Alex
U are correct in your interpretation of the uac2 descriptor
Uac2 is so flexible that there are many ways to skin the cat. We have been tweaking the descriptor to work with the uac2 drivers. We have been trying to make the descriptor and UAC request processing to be compatible with Mac OSX and Linux. At that point in time the Linux driver did not support clock multiplier. Even today the Linux driver clock selector/clock source is not able to parse some corner cases and we have to put in workarounds in the firmware.
So the current clock sources, one for the 44.1x sampling freq and one for the 48x freq is a good representation of the underlying hardware of two ultra low jitter XO's, as Borge has explained. This will pave the way for FUTURE drivers which can intelligently select and configure the best clock for the particular playback situation in the fly - ie without any re-sampling for bit perfect reproduction.
However, it looks like the current windows uac2 driver we are trying to interface with does not support clock selector. So we are planning to have a branch of the firmware that had only a single clock source and no clock selector. We will have a workaround such that all the 6 freq: 44.1/48/88.2/96/176.4/192 will be available and the firmware will switch the correct XO internally depending on the sampling freq set by the driver.
The descriptor will evolve as the driver/
Firmware get more aophisticated.
Alex
Interesting. I'm debating spending some time writing a driver as well, just to play around with. It seems like it shouldn't be incredibly awful; basically the MSVAD simple sample mixed with the usbsamp isochronous sample code and an intelligent DPC routine to efficiently transfer the data. Of course, the devil's in the details.
Windows-isms follow: it looks like the DPC just needs to pull from a WaveCyclic queue and transfer it appropriately--the "top" part of the driver that puts the bytes into the queue is basically the MSVAD driver. In fact, the MSVAD driver is overkill right now--it has volume control and other bits and pieces that are irrelevant, but it would be nice if the driver would configure the accessible parameters based on the available FEATURE_UNIT's, so it's nice to see how they're configured now.
The really unwritten part is the isochronous transfer to/from the endpoint that chooses the packet size based using feedback endpoint. I'm only looking at handling asynchronous UAC2, and am ignoring synchronous and adaptive transfers; they're probably simpler than asynchronous and might come for free if the rest of it works, but right now I don't really care. Or maybe I should start with synchronous and go from there? My own problems stem from not really having experience with USB that isn't on an embedded device (e.g. Cypress Semi's EZ-USB or AVR V-USB), and isn't a simple HID device. I've yet to read up on the isochronous feedback and synchronization mechanisms in the USB spec, and I know very very little about Windows WDF USB stack--I've used WinUSB, but it doesn't support isochronous transfers at all.
Really, we should all just be posting and asking MS on the wdmaudiodev listserv asking for a properly supported driver, because it seems like no one has talked about the absence of a UAC2 driver in Windows for a few years now. Maybe we all pitch in to spot them a device to experiment with, if they don't already have one? They're really great people over there; very smart, and they truly do care about the success of Windows. Open-source would be nice, closed-source free would be great too, but my personal preference would be MS-supported closed-source (MS-supported open-source being a pipe dream).
Windows-isms follow: it looks like the DPC just needs to pull from a WaveCyclic queue and transfer it appropriately--the "top" part of the driver that puts the bytes into the queue is basically the MSVAD driver. In fact, the MSVAD driver is overkill right now--it has volume control and other bits and pieces that are irrelevant, but it would be nice if the driver would configure the accessible parameters based on the available FEATURE_UNIT's, so it's nice to see how they're configured now.
The really unwritten part is the isochronous transfer to/from the endpoint that chooses the packet size based using feedback endpoint. I'm only looking at handling asynchronous UAC2, and am ignoring synchronous and adaptive transfers; they're probably simpler than asynchronous and might come for free if the rest of it works, but right now I don't really care. Or maybe I should start with synchronous and go from there? My own problems stem from not really having experience with USB that isn't on an embedded device (e.g. Cypress Semi's EZ-USB or AVR V-USB), and isn't a simple HID device. I've yet to read up on the isochronous feedback and synchronization mechanisms in the USB spec, and I know very very little about Windows WDF USB stack--I've used WinUSB, but it doesn't support isochronous transfers at all.
Really, we should all just be posting and asking MS on the wdmaudiodev listserv asking for a properly supported driver, because it seems like no one has talked about the absence of a UAC2 driver in Windows for a few years now. Maybe we all pitch in to spot them a device to experiment with, if they don't already have one? They're really great people over there; very smart, and they truly do care about the success of Windows. Open-source would be nice, closed-source free would be great too, but my personal preference would be MS-supported closed-source (MS-supported open-source being a pipe dream).
Hi Blushift et al,
U are welcome to try writing a windows uac2 driver as well. The more alternatives we have the better.
As I mentioned before, it is technically possible to write a windows uac2 driver that works with a single audio device. There are several commercially available drivers around. However, AFAIK, no one has written a driver that can work with a composite USB device that has uac2 plus something else eg HiD.
Async out is the most desirable mode for bit perfect low jitter transfer, but u might like to start with simpler modes first in the driver development.
Native uac2 support is available with OSX and Linux now. I am waiting for support under Android, which should happen soon as the Linux kernel is used in Android.
I think we will have working windows uac2 from Tsai or u much sooner than M$. It is nit that they are not smart enough to do it - it is the motivation or lack of
Alex
U are welcome to try writing a windows uac2 driver as well
. The more alternatives we have the better.As I mentioned before, it is technically possible to write a windows uac2 driver that works with a single audio device. There are several commercially available drivers around. However, AFAIK, no one has written a driver that can work with a composite USB device that has uac2 plus something else eg HiD.
Async out is the most desirable mode for bit perfect low jitter transfer, but u might like to start with simpler modes first in the driver development.
Native uac2 support is available with OSX and Linux now. I am waiting for support under Android, which should happen soon as the Linux kernel is used in Android.
I think we will have working windows uac2 from Tsai or u much sooner than M$. It is nit that they are not smart enough to do it - it is the motivation or lack of
Alex