Open-source USB interface: Audio Widget

Turbon,

Most of what you need can be found on MSDN and similar online resources, like the links below.
http://social.msdn.microsoft.com/Forums/en-US/windowspro-audiodevelopment/threads
FreeLists / WDMAUDIODEV

If you are game to tackle this (and its going to be hard if you are not a C++ Windows system developer) I recommend starting with the MSVAD virtual audio device sample in MSDN, all the DDK work is done for you, you can extract the audio data from the source application from the COPYFROM buffers and pipe it through your USB code.

I posted a bit of this information in the audio widget group last month, please check that thread - but I gave up on developing a UAC2 driver due to the work involved (as others have noted). I think there will be a number of UAC2 solutions coming out over the next 6 months but unfortunately not from Microsoft (it is not planned for Windows 8 at least from looking at the early releases) due to lack of demand. These third party solution (eg. CMedia) will have their own drivers tied to their hardware so it will probably not be possible to hack them in the DIY world.

I am going a separate route now, I will develop a custom driver based on the MSVAD sample and the Cypress CY7C68013A USB High Speed chip which has its own transport from the PC side to the chip (ie. no significant USB code to write!). The driver I'll implement will not be standards based, but then again for Windows you either have to purchase a 3rd party UAC2 driver or have a proprietary approach. I have discussed the pros/cons of this approach with Koon in his thread on a async USB High Speed I2S solution and he has a prototype working using a different chipset (its actually ending up to be a fairly simple solution).

Good luck & Happy Holidays!
 
Thanks for the support deandob! One of my strenghts is that I don't know when to stop. I am not to write the whole code but hopefully there will be those who will do it with people like me testing and scrutinizing their work. I might even write parts myself (good forbid) but the parts will be fully open to anyone to a view and comment on or show a better way. I do confess that writing low level windows system programs arn't something I have been doing since windows was young. The start and the easy part is to write a framework with what we know and if anyone is interessted comment more than less in the code assuming that people doesn't understand what the lines are doing. Personally I hate documenting...

The effort will be wholly community driven so people are invited to add as long as they want to - as soon as the code is checked in the ownership is transferred to the proper group - which I'm not totally aware of at this time. I know there is a group but I have seen no manifests yet. But the legal framework is easy to set up - I have some close contacts with people living on the subject so continue or start a new one is no problem - whichever as long as the code will be free to alter, use and even sell as long as the credits goes to the free project.

Brgds
 
Please follow the link from my signature and look at the module schematics. L1006 and L1007 are between USB VBUS/GND and those on the board.

The components are 0603. If you suggest any alternative components, please let me know! The ones used I copied from an unrelated USB design.

Oh, and if the sch/layout could be improved on, let us know about that too.
Last time I looked was the June 28 schematic, and I had not seen the USB module yet. I'm now looking at the July 3 USB module schematic...

I see that you have L1006 between the CHASSIS pins on the USB mini-B connector and the board GND, but that is not the correct placement. L1006 should be placed between the GND pin on the USB mini-B and the board GND. Remember that power flows in a circuit, so you should place the beads identically on the +5V and GND pins.

Meanwhile, the two CHASSIS pins should not be directly connected to ground because this will conduct shield noise into the board ground. Instead, create a high impedance filter with a 1 MΩ resistor and 0.1 uF capacitor in parallel.

Search for dsk5509a_Schematic.pdf and refer to sheet 13 of 17. This is a TMS320 DSP evaluation kit board schematic from Spectrum Digital that is available on their web site. The only thing I added that is not shown in the SD schematic is a cap across VUSB and GND that is ahead of the beads and corresponds roughly to your C1075 (assuming you break the CHASSIS ground away from the power GND).

EVM5509A Plus Support Home

P.S. My apologies for not noticing that you were already using beads. When someone suggested that you should always use a USB cable with ferrite beads, I immediately assumed that you did not have any filtering on your board. I think that if you move the bead on the ground then your board will work equally well with all USB cables.
 
Last edited:
I believe Alex played with the caps according to some older posts in the google audio widget group. Fo myself - I haven't even given them a thought since the s

Merry Chritmas and happy holidays to all :)

We are always happy to see reports on SQ on the analog mods. The major tweaks include using alternative power supplies (bypassing the onboard USB -> ADP151) such as the use of Silas Shunts or LiFePo4 batteries etc., and changes to the various caps.

Please first of all report your board's SQ based on the stock configuration so that we have a baseline. Is the sound better or worse than your previous DAC? In what way?

Now back to the question of caps. We have indeed played with the caps and they make a significant audible difference to the SQ.

First some theoretical discussion. If you know all of these already please skip this section ;)

The caps in use in practice are far from an ideal circuit element. Besides the basic capacitance value, there are other parameters such as the ESR, dielectric loss etc., which affects the performance. What and how caps should be used is also determined by the intended function (eg. whether you are bypassing the chip in question, or you are filtering the supply noise coming from outside the chip, or as a reservoir cap for charge pump etc.) Bypassing digital noise (eg for an XO) has different requirements from "smoothing" the supply for analog opamps etc.

To remove very high frequency noise from the supply line, you would like to use a small capacitance value. This is because the ESR (plus the circuit board reactance) and the capacitance value combined will dictate the resonance frequency - filtering will be most effective near the resonance frequency. So if you use just a high capacitance, such as 100uF, but your ESR is not ultralow, your cap can only deal with relatively low frequency noise and will be ineffective for high frequency noise.

So we have BOTH a low capacitance cap in parallel with a high capacitance cap to deal with both low and high freq noise. Using a 100uF cap may NOT be as effective as a 10uF cap if the noise you want to filter is 50/60Hz rather than 5/6 Hz :eek:

However, you cannot simply use any combination, as the two caps in the circuit may cause parasitic oscillations, and the resulting noise may be worse than the supply noise you want to filter in the first place. In general it is a bad idea to use two caps of the same value and type, eg 10uF + 10uF. It is safer to use a very small value in one, and a higher capacitance in the other. Again it depends on the ESR and other characteristics.

So choosing the right caps is a black art :eek:

If you look at the older posts in this thread, you will find reports of Wei using Blackgate-N caps to excellent effect. JKenny also reported his tweaks using other caps. I myself use Sanyo OSCONs (as I can't afford the Blackgate-N's). They have also reported the cap values used in various positions.

However, when you change the power supply (say to Silas shunts), the caps may have to be changed as the noise and impedance characteristics are different.

So much tweaking is requried - and that is the whole point of this project. Analog tweaking of the audio-wdigets is part of the fun

Alex
 
I don't know if the previous post applies to my request regarding the charge pump caps .... in any case, what is the default value of cap to be used there? I miss the complete es9023 datasheet, and before experimenting I'd like to avoid mistakes in values that can possibly damage the chip ...
 
You might like to refer to an old post to this thread in this forum. I have reproduced the content below if you are not up to reading old posts :)

Alex

On Tue, Jun 14, 2011 at 01:26, Alex Lee <alexlee...@gmail.com> wrote:
>> Hi all,
>> Wei (2A3SET) had posted his mods to the USB9023 board to the DIYaudio forum,
>> and the following is a copy & paste of his post:
>> =========================================================================== =======================================
>> Audio-widget with UAC2 driver runs pretty good, a big step up from UAC1 with
>> same 16/44.1 material. Very interesting, even with async mode under windows
>> 7 comparison between the minimalist(andy) audio player and foobar player
>> showed minimalist better, it shares same quality of sound with ecasound
>> under ubuntu studio.
>> I just upgraded the capacitors around ES9023 to BlackGate N, first tried the
>> VREG (10u) and Pump capacitor (4.7u) to bring SQ to a higher level with silk
>> smooth sound and quieter background, then the bypass for 3.3V (10u) and -3V
>> (4.7u) of ES9023. The onboard regulator ADP-151 sounds pretty good already,
>> although personally I think it worth a try to replace it with Salas shunt
>> (run as external modules). Anyway I am still pretty happy runing with USB
>> bus power so far.
>> =========================================================================== =======================================
>> He has done further mods and tests, with supplying an external clean power
>> supply to the ES9023 and to the Oscillator, with improved sound quality.
>> The SQ obtained has already surpassed Wei's own souped up NOS TDA1541 DAC.
>> He intends to compare the USB9023 with the Acko 9023 DAC in future.
>> We welcome more builders to do mods and report test results. These efforts
>> will help in improving the design of the next versions of audio-widgets.
>> George still has 11 bare boards and parts enough for 3 sets.
>> Borge is planning for the next run of AB-1 and maybe some of these mods can
>> go into the AB-1 as well.
>> Alex
 
Yes, you can latch onto the half-moon pads on the edge of the module. There's no dedicated I2S header. (Hint to self for revised layout...)
also a "digital interface" board with the AW uC complete with on-board clocks (and dividers) plus buffered I2S, MCLK and perhaps S/PDIF outputs would be nice for easy integration with existing DACs! ;)

Happy Holidays to everyone!
 
Catching up with posts here...

Starn02, the 4n7, if I remember correctly, is the largest C0G in 0603 form factor.

The CN / CP pump is specified to 1µF in an ES9023 data sheet. The low-ESR in parallel with it may actually be non-ideal and cause spikes. Feel free to try removing it and see if that improves sound quality.

As for all other supplies, I've just piled on decoupling :)

Børge

Hi guys,
I miss the complete datasheet of ES9023, so I wonder what's the reason behind the choices of capacitor around it.
I see a generic approach based on a parallel of: 4n7, 1u, 10u, 15u ... some of them installed, some not, for AVCC, VREG, NEG e between CN and CP.

I understand that some of the places on the board are simply for testing, but are there limits for some of the pins?

For charge pump capacitor (which I suppose is the one between CN and CP) are there suggested or limit values? Actually I have 1u in parallel with 4n7. Can I use also 15u?

And the 4n7 capacitors are to be considered as bypass? Why not the more common value of 100nF?
 
Thanks for your feedback on USB beading!! Duly noted. Will be implemented in next version.

I have actually run into some problems (which are probably ground loops) when I connect a bit too much (RS232, Atmel programming dongle) at the same time.

Børge

Last time I looked was the June 28 schematic, and I had not seen the USB module yet. I'm now looking at the July 3 USB module schematic...

I see that you have L1006 between the CHASSIS pins on the USB mini-B connector and the board GND, but that is not the correct placement. L1006 should be placed between the GND pin on the USB mini-B and the board GND. Remember that power flows in a circuit, so you should place the beads identically on the +5V and GND pins.

Meanwhile, the two CHASSIS pins should not be directly connected to ground because this will conduct shield noise into the board ground. Instead, create a high impedance filter with a 1 MΩ resistor and 0.1 uF capacitor in parallel.

Search for dsk5509a_Schematic.pdf and refer to sheet 13 of 17. This is a TMS320 DSP evaluation kit board schematic from Spectrum Digital that is available on their web site. The only thing I added that is not shown in the SD schematic is a cap across VUSB and GND that is ahead of the beads and corresponds roughly to your C1075 (assuming you break the CHASSIS ground away from the power GND).

EVM5509A Plus Support Home

P.S. My apologies for not noticing that you were already using beads. When someone suggested that you should always use a USB cable with ferrite beads, I immediately assumed that you did not have any filtering on your board. I think that if you move the bead on the ground then your board will work equally well with all USB cables.
 
"Bumper-to-bumper I2S" is when an audio bit is transferred on every single bit clock tick.

I2S has this weird thing about it that there is a dead clock tick between an word clock transition and the next data word.

When there are more ticks than bits, this tick is indeed dead. But when you're running bumper-to-bumper the LSB of the previous sample will arrive _after_ the word clock transition.

Let me know if you need code for this in Verilog. Do NOT let me know if you need sequensial code for this in an MCU :)

what do you mean? :confused:



Børge
 
Deanbob & Turbon,

A dummy audio device has been discussed here before. I think that's a good starting point.

Then there is the trick of making an UAC2 device enumerate and exchange some random data. Again: Two AB-1.1s go to whoever gets UAC2 enumeration and (annoying) sound with open source driver code on a Windows platform.

One idea is to let the ALSA code be the map for the Windows landscape which must be wrought. (Wrapper code is probably too much to ask for.) That means an important task is making the ALSA UAC2 code easily readable in terms of flowcharts and its API use.

I've looked into these challenges a bit. Here are some loose thoughts. Hope you don't mind my ranting...

MS won't make a driver. Their UAC1 code seems to be very convoluted. Their main audio driver coder left, I believe. They have more important things to do with Win8 GUI etc. There isn't enough pull from major vendors - I believe that's because enthusiast products have too much of an uphill battle with no Windows UAC2 driver, i.e. chicken/egg all over agian. And enthusiast product makers are scared of unfinished MS drivers. I can go on and on about why it won't come from there.

Only reason I see that it may come from MS is that it comes on Android first, then Win-mobile, and finally Win-PC. (Android as UAC2 host and streaming WLAN audio receiver would be interesting in itself...)

I have contacted some vendors already. Vendor X will only deal with larger makers who can afford their fees. They have no single-user licensing mechanism. Vendor Y is terrified about single-user support, and refuses even to sell $50 licenses where _this_forum_ is the only support. Vendor Z ties their driver to their hardware. IMHO they should give away the driver as minor-hassle-ware, make a name for themselves, and generate way more pull for their chips. But that's a lot to ask from any management team...


Børge

Turbon,


Most of what you need can be found on MSDN and similar online resources, like the links below.
Windows Desktop Pro-Audio Application Development Forum
FreeLists / WDMAUDIODEV

If you are game to tackle this (and its going to be hard if you are not a C++ Windows system developer) I recommend starting with the MSVAD virtual audio device sample in MSDN, all the DDK work is done for you, you can extract the audio data from the source application from the COPYFROM buffers and pipe it through your USB code.

I posted a bit of this information in the audio widget group last month, please check that thread - but I gave up on developing a UAC2 driver due to the work involved (as others have noted). I think there will be a number of UAC2 solutions coming out over the next 6 months but unfortunately not from Microsoft (it is not planned for Windows 8 at least from looking at the early releases) due to lack of demand. These third party solution (eg. CMedia) will have their own drivers tied to their hardware so it will probably not be possible to hack them in the DIY world.

I am going a separate route now, I will develop a custom driver based on the MSVAD sample and the Cypress CY7C68013A USB High Speed chip which has its own transport from the PC side to the chip (ie. no significant USB code to write!). The driver I'll implement will not be standards based, but then again for Windows you either have to purchase a 3rd party UAC2 driver or have a proprietary approach. I have discussed the pros/cons of this approach with Koon in his thread on a async USB High Speed I2S solution and he has a prototype working using a different chipset (its actually ending up to be a fairly simple solution).

Good luck & Happy Holidays!
 
Over USB it can be various formats. As long as we're using at least as many bits as the source material, we can zero pad all we want. Obviously, the used bandwidth must be within specs.

I may need some input from Nikolay and Alex on this one, but I believe we're transmitting 24-bit audio using 32-bit USB words and 24-bit DAC words.

The DAC uses 64 I2S ticks for 24+24 data bits. If it used the same 64 bits for 32+32 bits we'd have to confirm its bumper-to-bumper-ness. But at 24+24 the dead bit doesn't matter.

Børge

P.S. Enjoying kids in bed and calm piano music on real-time spline interpolator (aka homebrew CD player)

:D

actually I was just wondering what does this mean in practice WRT 24 vs. 32 bit. Isn't data always sent encoded in 32bits over the USB?
 
What is your recommended Software BOM?

What would you recommend as a first experiment in Unix for USB2 music from a laptop. This can be a dedicated machine with no other use than playing music in its finest form.
I have never used UNIX, and do not want to pay for it. I view it as a learning experience and an opportunity to see the advantages over WinXP for this application.
What version of Linux/the player. Where would you refer me to read and research.
Thanks in advance
 

Attachments

  • AW-AB1.1-mod1.jpg
    AW-AB1.1-mod1.jpg
    232.8 KB · Views: 251
  • AW-AB1.1-mod2.jpg
    AW-AB1.1-mod2.jpg
    966 KB · Views: 246
  • AW-AB1.1-mod3.jpg
    AW-AB1.1-mod3.jpg
    444.7 KB · Views: 229
Last edited:
I may need some input from Nikolay and Alex on this one, but I believe we're transmitting 24-bit audio using 32-bit USB words and 24-bit DAC words.
at least in Linux that's for sure, even for 16 bit (CD) source material:

$ cat /proc/asound/card2/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
[...]

I was wondering what happen if I send a truly 32bit stream.

real-time spline interpolator (aka homebrew CD player)
that sounds interesting... could you open another thread and tell us more about it? :cannotbe: