Open-source USB interface: Audio Widget

I'm trying to play ISO SACD files but I don't get any sound in the speakers.
The widget does NOT support DSD, only PCM!

You may play those files only if the player (foobar or whatever) supports their format AND is able to read, decode and convert them from DSD to PCM.

Before trying something which may introduce unrelated problems, I'd suggest you to try playing regular PCM files (flac or whatever). Try those which work in UAC1 first: they must work in UAC2 too.
 
On Windows, an Audio Widget DAC in UAC1 mode is not reached by the project's ASIO driver "ASIO_UAC2" (but you may explore ASIO4ALL if you want.)

Also on Windows, a DAC in UAC2 mode is _only_ reachable through the ASIO_UAC2 driver.

For the ASIO driver to work, two things must be in place:
- The DAC must be in UAC2 mode / red light
- The player must support ASIO.

Foobar2000 requires an ASIO plugin and that you manually select ASIO_UAC2 as the output. See the attachment for how I have f2k running on my computer.

There may be two other issues. 1 - your computer is too slow or has too much to do. See if the DAC works on a >Core2Duo 2GHz computer which has nothing other to do than the music playback. 2 - Your firmware may be corrupted or out of data.

To install new firmware, read the text at line 508 of
https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/AW_readme.txt
and follow it religiously.

Apply this instruction to the firmware image at:
https://github.com/borgestrand/widget_binaries/blob/master/awx_20140917_silent.elf?raw=true


Best,
Børge
 

Attachments

  • a.png
    a.png
    154.6 KB · Views: 788
I'm not sure where to ask this question, or who to address it to. Please give me your suggestions for a more appropriate place if you can.

I am attempting to compile the Win-Widget ASIO driver source code from the exp-asio branch. I downloaded the zip file from github. After adjusting a few paths in the asiouac2 project, I got it to compile and almost link. I've hit a problem, though, that I could use advice or help with.

The problem is that most of the functions in libusbK called by uaclib in this project are not recognized by the linker. For example, the first link error says:

Error 7 error LNK2019: unresolved external symbol UsbK_ClaimInterface referenced in function "public: bool __cdecl USBDevice::UsbClaimInterface(unsigned char)" (?UsbClaimInterface@USBDevice@@QEAA_NE@Z) E:\Documents\Electronics Projects\I2S\ASIO Drivers\Win-Widget-exp_asio\Driver\uaclib.lib(USBAudioDevice.obj) asiouac2


The problem as I see it is that the ClaimInterface function in libusbK takes three arguments, whereas uaclib passes only one argument, and that argument seems to correspond to the second argument expected by the function.

I am using the copy of libusbK drawn from github as part of the project, and I have not modified it.

My immediate reaction is to ask whether the right version of libusbK was checked in to the project. The code in uaclib appears to have been written for a somewhat different interface.

I think it is a good idea to keep up with libusbK releases, and I am willing to do some work to make this code compile, link, and run. But some guidance would be much appreciated.
 
Hi,

I just merged my exp_asio_local into exp_asio and pushed it. You may have better luck with this one or other resent commits. One thing which I hadn't pushed until today was the removal of excess files from the libusbk-dev-kit folder. I'll try to do a re-build later today and see how things fit together on my machine.

The libusbK version checked into the repository is not up-to-date. It was chosen to do it like that so that new versions of the driver dll didn't require the kernel-mode part (libusbK.sys and friends) to be updated every time group memebers wanted to try out the new build.

There's probably a better way to do things, and keeping up with libusbK's releases is more than likely a good idea. Unfortunately, I don't have much skill in setting up Windows installers, I have merely repackaged Nikolay's work with minor tweaks.

I believe that for testing releases with up-to-date libusbK test users should use the installer and not simply copy in a new .dll. For that the installer should be capable of uninstalling previous versions of libusbK with minimal hassle to the user and implications for system stability. Perhaps it already does that?

One thing I've been working on lately is improving 64 bit support. There is a package of 64-bit binaries and a .reg file which can be copied manually on top of the driver installation, and at least some programs requiring 64-bit ASIO will work. However, this is not yet automated. A friend of mine has suggested changes to the .inf file to take care of this, and I have started messing with the installer. But this work is far from a conclusion.

The package is ASIO_bin_patch_20140429.zip of https://github.com/borgestrand/widget_binaries. Most likely, commits from around that date might be less broken :)


Good luck, and keep us posted. I will try to do a new build on my system and see if I get the same errors as you.


Børge
 
Last edited:
Thank you, Børge.

After adjusting many of the paths in the project files, I was able to successfully build both your latest checkin and the previous one. I think the X86 version of libusbK was in the path for the 64 bit version, so it did not link successfully before. But I still do not understand why 1 versus 3 args to libusbK is not an issue now. I must look at the code more closely.

There seem to be 2 versions of libusbK 64 bit, one for Intel processors and one for AMD processors. Are you building different versions of the driver for the two different processors?

David
 
I'm happy to report that the open source ASIO driver in this project works with an XMOS-based I2S converter. The I2S converter is Weiliang's adaptation of the XMOS 2-channel audio evaluation kit. I'm now playing music using J River Media Center through the asiouac2 ASIO driver to the Weiliang DAC.

This is exciting to me because I've been looking for an alternative to the USBStreamer for multichannel I2S conversion. Finding a suitable Windows driver was always the problem. I think the asiouac2 driver will work with an inexpensive XMOS-based multichannel I2S converter, which is what I'm going to work on next.

Many thanks to the contributors to this project, including you, Børge, and especially Nikolay Kovbasa, who seems to have written the driver.

David
 
David,

this is fantastic news!! I've always had the hope that our open source driver would attract other USB hardware than just the SDR and Audio Widget derivatives. Now, it's easy to add support for your hardware in the official version of the driver, but it'll have to be based on USB VID/PID.

Nikolay did 99.99% of the driver work. My only contribution was a little tweaking of the feedback algorithm inspired by the analogous code in the Linux kernel.

If you feel adventureous you can also try out the .wav file player in WidgetTest :)



Børge
 
Sooo... a few weeks back I finally dug the USB5102 audio widget kit I bought from George a couple of years ago out of the drawer and took a stab at it. I decided to give the SMD hotplate idea a go, and while it seemed to work well, I ended up using way too much solder paste and had to wick off a lot of extra solder from the Atmel CPU's pins.

If I understand the readme correctly, the device should respond in some way when plugged in to the USB port, even before firmware is loaded.

Unfortunately when I plug it in, either in Windows or Linux, I'm getting a "unknown device, not responding type of message"

In LMDE Mint (Debian version), I get the following in dmesg:

[ 956.568030] usb 5-2: new low-speed USB device number 2 using uhci_hcd
[ 956.692016] usb 5-2: device descriptor read/64, error -71
[ 956.916023] usb 5-2: device descriptor read/64, error -71
[ 957.132052] usb 5-2: new low-speed USB device number 3 using uhci_hcd
[ 957.252020] usb 5-2: device descriptor read/64, error -71
[ 957.476023] usb 5-2: device descriptor read/64, error -71
[ 957.692020] usb 5-2: new low-speed USB device number 4 using uhci_hcd
[ 958.100020] usb 5-2: device not accepting address 4, error -71
[ 958.212017] usb 5-2: new low-speed USB device number 5 using uhci_hcd
[ 958.620025] usb 5-2: device not accepting address 5, error -71
[ 958.620045] hub 5-0:1.0: unable to enumerate USB device on port 2

If I've cooked the CPU, then It may not be worth my while because it will be a beeatch to remove/replace it, but I was wondering what kind of troubleshooting I might do before I write it off. I have a scope so I could look for signals if it is worthwhile, but not sure where to start.
 
It will probably work only on PCM5102 version...AB-1.1? I think.
The AB-1.1 was based on the "little Sabre", the ESS ES9023 DAC, not the PCM5102:

Q N K T C USB-I2S Module and Analog Board 1.1

I haven't had a chance to listen to the new ABs, but 1.1 was (and still is) really a little jewel. With only minor, inexpensive modifications (just a few good caps added here and there in the "right" spots and a single good +5V external linear PSU) it sounds incredibly close to my new "main" DAC (based on AK4490 with Xmos USB interface, of course AC-powered with plenty of independent low-noise linear PSUs, etc), which is far more complex and expensive than the little old widget.

It would be nice if it may be updated to support even the few "extreme resolution" files available. :)

BTW: what do you think may be the possible consequences of the mod on SQ, if any? May the removal of the flip flop divider possibly reduce jitter (thus possibly getting even better SQ) or on the contrary it may have drawbacks detrimental to the overall SQ?
 
Last edited:
Hi Borge et al.

Is there a version of the code for AB-1.1 that works with the newest driverinstallation from Henry Audio.
Sorry to say I don't remember what version I loaded last time and the HD I used is gone:(. I can switch between uac-1 and 2 with widget control but there are som artifacts in the sound even with uac-1.

Regards