Open-source USB interface: Audio Widget

Thanks Michael!

I did the math, and the expected output is 420.5130385, 440, 459.4869615, respectively, so I think we can conclude positively on that test.

Børge

Hi Borge, all,

I did a quick test with AB-1.1 set to "uac2_audio" and stock firmware, supplying an external synthesizer clock.

With a 440Hz test signal generated by sox -r 88200 I get the following output:

21.5792 MHz -> 420.5 Hz
22.5792 MHz -> 440 Hz
23.5792 MHz -> 459.5 Hz

Now, does this qualify as asynchronous?

Hope that helps ... Michael
 
Here is an overdue response to an older post.

Audiodesign, I assume you're referring to the WDK. I'm downloading it from Download: WDK 7.1.0 - Microsoft Download Center - Download Details and plan to play around with it.
...
Børge

There was generally very little of audio stuff in the WDK but it's a good starting point on how to think. The USB Device Viewer (uvcview.exe) seems to be a usefull tool. I haven't got in very deep into the WDK but there should be a list of all descriptor tags (or headers?) somewhere in it.

Brgds
 
All the recent rumours about USB audio quality is about the implementation of the hardware in a way that the board itself asks for the data, and has on board clocks ..
this is how the Audio Widget works.

The master clock is on the DAC (two of them, actually; one for 44.1K and multiples, another for 48K and multiples) and that is what is sent back to the USB/I2S interface.

UAC1/2 Async protocol (which are official standards) works by means of "rate feedback". If I have understood correctly the details, the data on the USB bus is sent isochronously (obviously clocked by the USB clock) but the amount of data transferred in each block is adjusted according to a rate feedback (sent back by the Audio Widget to the PC) so that the overall data rate on the USB bus corresponds to the data rate "required" by the destination clock. Given that, at the "receiver" end the stream can be (synchronously) reclocked using the DAC (local) master clock. The overall result is an asynchronous data transfer. The "dances" are indeed led by the Audio Widget clock (better yet, by the DAC local clock).

I assumed that the Audio Widget was implemented this way ... at least with UAC2. Am I wrong?
No, you aren't. Not only in UAC2, but also in UAC1. The only practical difference between AW's UAC1 & UAC2 modes is the max sampling rate allowed (which is limited to max 48K in UAC1).

The Audio Widget was NOT designed to be used in pure isochronous mode, ever.

I get some edgy highs, I also tried the output caps ...
most likely the poor SQ are because of the power supply. Using USB power comes handy for portable use, but was really a bad idea for overall SQ. :(

Common mode noise coming from the PC via the USB connection is another problem.

ALWAYS use an USB cable with ferrite beads at the ends. That makes a lot of difference in SQ!

Check also the software: without some special care and software, windoze (and XP in particular) is really bad for audio. I second the suggestion to try with Linux first. For a test, also a live CD will do. ;)
 
Last edited:
Given that, at the "receiver" end the stream can be (synchronously) reclocked using the DAC (local) master clock. The overall result is an asynchronous data transfer. The "dances" are indeed led by the Audio Widget clock (better yet, by the DAC local clock).

Thank you very much for the reply.
So, UAC1 and UAC2 work with asynchronous data transfers. Rate feedback is used to ask the PC to adapt the rate so that the buffer on board is never empty or never overflows. PERFECT.

Now, what you mean by the phrase above ... "the stream can be (synchronously) reclocked using the DAC (local) master clock" ?
You mean that data is simply sent out along I2S at the rate given by the crystal, or that there is some interpolation / repetition /drop o samples?

I took a look at the code and what I understood is that there's rate feedback but no such sample rate conversion, which should be enormously bad. My understanding of the code is limited, also because I fear that the one that I can get to following the links is outdated ... no trace of ES9023 or 9022 ... maybe an old version? Can somebody tell me where can I find the source for "audio-widget-from-George-2011-11-29.elf " firmware?

In any case, I'm sure that in my case thare's something severely wrong with playback. There's high frequency distortion, and something else that's difficult to explain, but has to do with music "pace", the sense of rhythm of music .... something like if music was continously changing "pace" (and this led me to remember some document describing the behaviour of adaptive isochronous chips like PCM2906, where the actual clock is recomputed and changed more or less 250 times per second to match the incoming data rate ...).

Yesterday evening I performed a test. I tried to reflash the firmware on the board using "audio-widget-from-George-2011-11-29.elf " fearing that the one coming with the board was old or broken. After some problem (please somebody CLEAN the documents about loading firmware ... some are wrong) I completed the task.

Now, when playing back at 192 Khz the pitch of music is decreased ! There's a change in tone. This did not happen with the stock firmware.

Can somebody tell me which is the firmware that I should use with a board with 20110716 date?
 
Hi Starn02,

1. The audio-widget-from-George-2011-11-29.elf firmware is good. It is actually meant for George's USB9023 board, not Borge's AB1.1. But it will work equally well once you use WidgetControl GUI tool to set the parameters for usbi2s (instead of usbdac). For Windows, select uac1_audio. For Linux and OSX, sselect uac2_audio.

2. To browse the source code, you need to use git. If you don't know how to use git, perhaps you can try the github website and use the webbrowser interface to browse the source code.

3. The branch that is for the audio-widgets (ie AB1.1 and USB9023) is called audio-widget-nik. In git, you need to issue these command:

$ git clone git://github.com/amontefusco/sdr-widget.git
$ cd sdr-widget
$ git checkout audio-widget-nik

Then you can browse the source using an editor.

3. The audio-widgets are running async out with rate feedback. NOT adaptive. NOT synchronous. Period. I am not here to convince you that it is so. If you don't believe, it is fine with me :)

4. Just try your audio-widget with Linux or OSX (with the proper software and audio settings). If you still get poor SQ, there maybe something wrong with the hardware. Also try with another PC. Some PC's have poor USB +5V. If the voltage is too low or the supply too noisy it will affect the SQ.

5. How did you play back 192khz music? With Windows? That is not advisable unless you have a uac2 Windows driver.

6. Please remember that this is a diy project. We are all volunteers and hobbyists and we are donating our precious time and talent for the benefit of other experimenters. We are not a big commercial company out to get money from you. So DON'T expect full documentation and step by step guides. DON'T expect things will work out-of-the-box without tweaking.

Alex
 
Alex,
you don't have to convince me, it's just that there are a lot of documents and versions and I'm trying to figure out what's the situation.
You say that the board is async and not adaptive, and I believe you.

In my case there's something wrong with playback, and I'm trying to sort out the cause.
I actually work on windows Xp. I found a way to modify an existing driver for UAC2 and it seems to work OK, although it's just for testing. I suppose there are many ways to "force" windows to serve UAC2 compliant devices.

I will check the code, and perform some measurement on the hardware. If I find some cause of my situation I'll report here.

Starn
 
You mean that data is simply sent out along I2S at the rate given by the crystal, or that there is some interpolation / repetition /drop o samples?
not sure about that (I've not participated to the development). AFAIU it's the former, but let' wait for some of the developers to step in for an authoritative answer...

I took a look at the code and what I understood is that there's rate feedback but no such sample rate conversion, which should be enormously bad.
why? you need not to do any conversion! All that you need is a (FIFO) buffer (which I guess exists in the uC). The uC itself is also driven by the DAC clock.

Moreover, any SRC may/will alter the data stream, thus affect adversely the SQ!

no trace of ES9023 or 9022
why there should be any?

In any case, I'm sure that in my case thare's something severely wrong with playback. There's high frequency distortion, and something else that's difficult to explain, but has to do with music "pace", the sense of rhythm of music ....
which OS are you using? with which software? and which driver?

Yesterday evening I performed a test. I tried to reflash the firmware on the board using "audio-widget-from-George-2011-11-29.elf " fearing that the one coming with the board was old or broken.
nope. I never cared to reload the firmware, the stock one works perfectly. I use it regularly with Linux (that's what I use everyday on all my computers...) in UAC2 mode, but have tried it also on a win XP machine of a friend (of course only in UAC1 mode, 44.1/16 CD source material, using Foobar as the player).

Now, when playing back at 192 Khz
how can you play 192K on windows?
 
I found a way to modify an existing driver for UAC2 and it seems to work OK
perhaps not quite so...

First of all, reload a proper firmware for the AB1.1, like the stock one. The front LED "color code" to display currently active mode (RED=UAC2, GREEN=UAC1) and the mode-switch via button are quite handy. ;)

Try (non-resampled) CD material using UAC1 mode first. Use a player like the recommended "pureplayer" or Foobar, in "bit-perfect" mode (no resampling!).

Then switch to UAC2 and try re-playing the same material, in exactly the same way.

You should hear no differences whatsoever.

If you do, your mod. driver is not working properly with the AW...

If they sound the same, then the problem is elsewere. Maybe a defective AW or -more likely- a problem with the host PC (hardware and/or software).

That said, an USB cable with ferrite beads at the ends is IMHO mandatory for good SQ. It may sound pretty bad without the ferrites.

If you happen to have one, try using a "double-power" USB cable. That is, one which have two USB plugs to use power from two ports on the host. Some 2.5" portable HDD come with such "strange" cable. It usually also improve a bit the SQ (it must have ferrites too! or you have to add some).
 
Last edited:
I've followed the links from your there. This one puts things into perspective in an interesting way: Kernel-Mode WDM Audio Components

Looking at the sheer number of drivers which interact, I can totally understand how things like Asio and Jplay surface....

Here's my theory: Microsoft's current UAC1 implementation is so convoluted that nobody in their right mind would touch the code. Looking at all the modes their UAC1 supports, it looks like feature creep de luxe.

Any more indications on the UAC1 driver source being available?

Børge

This seems to be a good educational resource:

Audio Miniport Drivers

Brgds
 
Hi Starn,

please try the signal generator I linked to, and see if you can scope the outputs. Then we can help you sort things out.

Børge

In my case there's something wrong with playback, and I'm trying to sort out the cause.
I actually work on windows Xp. I found a way to modify an existing driver for UAC2 and it seems to work OK, although it's just for testing. I suppose there are many ways to "force" windows to serve UAC2 compliant devices.
 
Hi Starn,

Here is a firmware image update. Go to Downloads - sdr-widget - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting for downloads.

Actually, to manufacture an AB-1.1 it is first programmed and tested with testblink_defaults_20111219b.elf. This image plays audio, but has not been updated in a long time. Instead each reset on this image sets the eeprom defaults so that I don't have to run WidgetControl for each board. After reset it performs an LED test sequence.

After passing this test each AB-1.1 is programmed with audio-widget-nik-20111016b.elf.

However, this image may be getting a bit old. So I compiled and tested today's code in the git repository. I've tested the result in UAC1 and UAC2 on a Win7-32 computer. No issues. File name is audio-widget-nik-20111222.elf For the AB-1.1 this seems like as good an image as anything else to date.

Børge
 
Wow, a new image, I had already finished reflashing "audio-widget-nik-20111023.elf", and things seemed rather improved ... playback ok at all rates, including 176.4 and 192k ....

About sound quality, I would say it's improved a lot ...

Now you say I should re-flash again to the latest firmware?

In any case, my "home made" UAC2 windows XP driver seems to work very very well ..
 
Wow, a new image, I had already finished reflashing "audio-widget-nik-20111023.elf", and things seemed rather improved ... playback ok at all rates, including 176.4 and 192k ....

I don't think things have changed very much since then. But feel free to try the new image.

About sound quality, I would say it's improved a lot ...

Good! I've heard others say that too, without really trying to figure out why. But if this is your experience, it'll be the new image in AB-1.1 from now on.

In any case, my "home made" UAC2 windows XP driver seems to work very very well ..


Congrats. I just wish someone would be willing to sell us legal single-user licenses. Alternatively, the first chip manufacturer who gives out an all-served driver will become the houshould name in their business, and gain tremendously from it.

... okay, done ranting for now...

Børge
 
ALWAYS use an USB cable with ferrite beads at the ends. That makes a lot of difference in SQ!
... USB cable with ferrite beads at the ends is IMHO mandatory for good SQ. It may sound pretty bad without the ferrites.
When designing USB boards, I place the ferrite beads on the PCB so that it works equally well for all cables. I realize it's too late to modify boards in the field, but if you revise the PCB then I suggest adding ferrite beads and other appropriate filtering on the PCB.