Open-source USB interface: Audio Widget

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.
probably the easiest way to begin playing with Linux would be to install a full distribution such as "Ubuntu" (perhaps the "Ubuntu Studio" variant). But, for a dedicated "music machine", IMHO the best thing to do is to use a dedicated system already optimized for audio, such as Voyage MPD.

For the easiest doployment of Voyage MPD you'll need a LAN with a small router (providing DHCP) connected via Ethernet to the machine that will act as "music server" (WiFi configurations are possible too, but a bit more complex to set-up).

After configuration, the "music server" (the machine connected to the audio system) wil run as an appliance without the need for a local user interface (not even a display).

It will be remotely controlled from user interface(s) running on other machines/devices (even including hand-helds), namely MPD clients.

Among these, for use on a computer (another laptop/netbook or a desktop, with either Linux, Windows or MacOS/X), I'd recommend the nice, easy and featurefull "GMPC".
 
Last edited:
I found the output low pass filter was important, at least with wide band electronics following. The uhf stuff at the output is significant.
what values have you used for R and C?

(I like the possibility to directly drive my hearphones too, thus the R must be kept very small. I guess no more than a few ohm. What about f3? 40KHz could be ok?).
 
Member
Joined 2004
Paid Member
what values have you used for R and C?

(I like the possibility to directly drive my hearphones too, thus the R must be kept very small. I guess no more than a few ohm. What about f3? 40KHz could be ok?).

My notes are here: http://www.diyaudio.com/forums/digital-source/185761-open-source-usb-interface-audio-widget-28.html#post2747950

I have not dug further into the limits but you may be hitting a brick wall with the ESS9023. The part meets or exceeds its published specs in this system. It does have some odd issues, overload is a specific one with the datasheet talking about a resistor (R15) affecting its clipping performance. It seems R15 sets the Vref for the DAC so its value and the optimized grounding of the associated caps will be critical. Keeping the digital and analog grounds isolated is challenging in a small device like this, especially when the analog power is derived from the digital side and there is no practical way to fully isolate the USB system from the DAC. This said I believe really close study of the PCB and its power and ground for the analog system, possibly even disconnecting all the analog ground connections and using a star ground (wirewrap wire would be OK on this side) could make a big difference in the final sound.

The spec sheet calls out the 4n7 caps on the output, and it also says the load must be higher than 10K (at least for the spec measurement) (no headphones here). The Nuforce U-dac that uses the same DAC chip uses a TI TPA4411 output amp, which helps a lot.

Its clear that the chip could benefit from some very careful supply and grounding help. However my experience suggests looking at the AKM4430 http://akm.lfchosting.com/datasheets/ak4430_f01e.pdf may get a better sound in this application (and possibly cheaper). Its only 16 pins and has a charge pump. The pinout is enough different that its not a drop-in.
 
d that I was happy with:
1) 25 uF cap in C34
mmmh, may be I went a bit too far on this one with 47uF? :cannotbe: I'll try with smaller values too.

2) 470 uF 25V caps in C21 and C31
makes sense... unfortunately I did not have suitable parts at hand. Maybe I should get and try those Panasonic. Indeed, having the cap after the v.reg. larger than the one before it is something I didn't quite like. OTOH, I wanted to have small Xc @ low freq (and plenty of stored energy) as close to the analog circuit as possible. I don't quite like the idea of audio signals circuit closing through a voltage regulator. I definitely prefer it to close (as much as possible...) through just a capacitor. Non-ideal as it can be, yet better than the complex active circuitry of any voltage regulator.

Oh, BTW: the link does not work! :( Could you please provide a correct one?

3) 6.8 nF polystyrene caps at C251 and C253
so you just added the caps, without replacing the 0R with a true resistor (or inductor)?

4) Ferrite donut on the USB cable.
sure, me too. :)

I'm looking forward to the future variants of this technology.
yup... it's time to gettin' serious, with a fully self-powered and fully dual-mono unit based on a couple of top-end DAC chips. Possibly also with optoisolators between uC and AB. ;)

The AB1.1 is nice and sounds quite well, but it's still far from the SQ of my current setup. ;)

Especially for what regards sound "richness" and "imaging". With my reference setup the latter in particular is kind of magic. Virtual image usually extends well over the limits of the speaker positions: (with some recordings) it may get close to a 180° sound stage, extending almost to the sides of the listening position! While still being perfectly stable, properly sized and focused (no, I don't use ambiophonics or any other sound processing).

On the contrary (all the rest being the same) with AB1.1 the image is always enclosed in the space within the speakers. :( (and it's also somewhat less stable/clear/defined than my reference).
 
Last edited:
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)

Hi Borge, Unix-man et al,

The "old" firmware (ie not the latest firmware I just built today), in the audio-widget-nik branch, uses, for uac1 24 bit USB and 24 bit i2S transferred to a 24 bit DAC. In uac2, it uses 32 bit USB and 24 bit I2S. The least significant 8 bits are truncated on transfer to the I2S bus.

My latest firmware (audio-widget-nik-2011-12-26.elf, which you can download from the code page), does FULL 32 bit transfers from USB to I2S to DAC, under UAC2.

So now it is up to the DAC to interpret the 32 bits coming in through the I2S bus :)

I have just tested it with my AB1 and it sounds exactly the same as the old firmware (which is expected).

So Borge: bumper to bumper I2S seems to be OK in the AW :D

I will have to wait for George's 32 bit DAC to arrive to tell the difference ;)

Alex
 
Hi Alex,

sorry for the double posting... But the only way to test the bumper-to-bumper stuff is to scope the data line at word clock transitions. With known data (for example all 4 least significant bit being the same, and different from the MSBs) it is easy to see.

But to listen for a properly conveyed 32-bit LSB may be a bit tricky :)

Børge
 
Great advice

probably the easiest way to begin playing with Linux would be to ...

Thanks UnixMan. This is exactly the kind of advice I was looking for. I will likely take this one step at a time, but I must admit, the dedicated appliance is where I would like to land. The concept is elegant in its simplicity. There is no extraneous hardware or software at the player. Also, I love the simplicity of the linear power supply, and the isolation from all the hdd/monitor etc.
 
Thanks UnixMan. This is exactly the kind of advice I was looking for. I will likely take this one step at a time, but I must admit, the dedicated appliance is where I would like to land. The concept is elegant in its simplicity. There is no extraneous hardware or software at the player. Also, I love the simplicity of the linear power supply, and the isolation from all the hdd/monitor etc.

Yes, a dedicated machine will my next step as well but for now I chose the fat lady - Fedora 16 KDE on an old laptop. Imagine that wireless worked right out of the iso file! Now I need some lightweight no fuss players.

Brgds
 
Greetings.
I received the sdr-widget AB-1.1 DAC. Great sound.

I would try external source to clock and DAC. Where is some information to make an external source for the AB-1.1?

I have doubts about the operation.

- J2: 3.3 V. --> VDD_SENSE VBUS_EN (off). (Then ADP151AUJZ_3.3 regulators OFF.)
Can be applied:
- J3: 3.3 V. 75 mA VDD_XO.
- J4: 3.3 V. 30 mA for analog DAC AVCC.
Would this be aproximately correct to begin?
 
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?
At the highest level, USB is always 8-bit data. All data formats are expressed as collections of 8-bit bytes. Within the USB Audio Class, audio is sent as 8-, 16-, 24-, or 32-bit samples. A separate parameter specifies how many bits are valid, allowing 12-bit and 20-bit or other rare formats. The clock rate for USB data is fixed by the host, which is why UAC asynchronous uses rate feedback to control the effective sample rate.

Note that if you are running into USB bandwidth issues, then it might make sense to change from 32-bit samples to 24-bit samples, especially if your source data is only 24-bit anyway. Using 32-bit samples over USB just takes 33% more bandwidth with no benefit other than the fact that it's the same format when you do have 32-bit source material.

The I2S is completely independent of the USB format, with the obvious exception that the overall bandwidth cannot be exceeded. I2S is truly serial, with no requirement that the bit count be a multiple of 8. I2S Master and Slave can even use a different number of bits, with the understanding that the Word Clock will select the Most Significant Bit and any extraneous or missing bits will fall at the end of each word. The critical aspect is to align the MSB, although you might not be able to tell that it's off by one unless you have careful test data.

The bit clock rate of I2S determines the maximum sample rate, combined with the bit depth. If you have a low bit clock rate and a large sample bit depth such as 32-bit, then your maximum sample rate will be lower than if the bit depth were dropped to 24-bit. Using a higher bit clock rate allows the bit depth to be 32-bit without hitting any limits. Basically, the difference between the bit clock rate divided by the bit depth and the sample rate determines how many 'empty' bits there are between words on the I2S. At high sample rates, there may be 0 'empty' bits between words, and that's what people are concerned about. Different hardware will have different success at these extremes. Some serial peripherals will have no problem with back-to-back sample bits, while others will be flaky. Since the Audio Widget is fixed, and folks here have already reported success, then the only problem might be the DAC at the receiving end. Also, if future Audio Widget change the hardware for the I2S Master, then there might be opportunity for problems at the extreme.
 
If you use KDE, the natural choice would be "AmaroK"... but I'm afraid that doesn't exactly match your "lightweight no fuss" specs. :)

For a desktop based stand-alone player that match your requests you may want to have a look at gogglesmm (Goggles Music Manager).

Nah, amarok was about the first to be removed. Well, gogglesmm seemed to follow the rest of the pack with willingness to organize my media and so forth... I like vlc even though it isn't really lightweight. I would like something as pureplayer for linux that gives a sh*t about my media! It should really just ask what file or library do you want to play... Easy as that or can I just pipe a file to the device? In that case I can write my own script to use.

Brgds

Sorry folks, a bit OT... But still destilling what I need to check the AW out with my terms...
 
Well, gogglesmm seemed to follow the rest of the pack with willingness to organize my media and so forth...
no, not necessarily.

It should really just ask what file or library do you want to play... Easy as that or can I just pipe a file to the device? In that case I can write my own script to use.
oh... than you came to my own favourite "player":

Code:
 AUDIODEV=hw:1,0 play *.flac

The command "play" is just a different name for "sox". Install sox and all of its plugins and you're done.

(setting the "AUDIODEV" env. variable is only needed if you want to output to a device different from the default one).