Open-source USB interface: Audio Widget

[UnixMan]

Could you try to rerun the test cases which needed the _LINUX_QUIRK?

I just tried a few mixed-sample-rate playlists (which used to give some troubles with an older firmware) and it worked like a charm. :happy:

(I tried with "linux_quirk" enabled; have to try with it disabled too, just to cross-check).

 

[Mjjg]

Hi Mjjg,

The mystery thickens. I downloaded the latest dfu-programmer from the svn repo (without any hacking to work with sdr-widget) and also built the latest libusb-1.0.8 from source. And the same link error occurs.

Anyway if you are using x86_64 here is the binary for U11.10:

dfu-programmer - sdr-widget - hacked dfu-programmer binary for x86_64 - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting


Alex

That worked like a charm. Thanks!

 

[borges]

I just tried a few mixed-sample-rate playlists (which used to give some troubles with an older firmware) and it worked like a charm. :happy:

(I tried with "linux_quirk" enabled; have to try with it disabled too, just to cross-check).

Good! Please check. They are supposed to be different. I did check that the feature is visible by code, and I took out my test case before committing to the repository. I did not check the actual Linux Quirk functionality.


Børge

 

[borges]

New HW batch arrived

Here is the first picture of the AB-1.12/1.13 prototype boards and the next module!

I'm already playing music on this setup, but it looks like some debugging is needed. The boards look OK, and I hope to start shipping them out soon. I'll keep you posted.


Børge

 

[borges]

Hi guys,

I have received the AB-1.12 / 1.13 prototype boards and a batch of new USB-I2S modules. Follow the link in my signature to learn more.

Cheers,
Børge

 

[UnixMan]

Some more testing done.

Fisrt of all, "linux_quirk" confirmed (Linux 3.2, ALSA 1.0.24).

Without it, switching from a 16/44.1 stream to a 24/96 one will mess up playback.

This happen even if the lo-s/r track playback is stopped (by pressing "stop") before starting the hi-s/r track playback. Only pressing "stop" and then "play" again after the hi-s/r track (messy) playback have been started fixes the problem.

Curiously, switching between 16/44.1 and 24/48 works just fine.

Perhaps the problem arose only when the s/r difference between the two streams is large?

Switching back to lower s/r (24/96 -> 16/44.1) seems to work without problems also without "linux_quirk".

(player used for these tests: "gogglesmm" version 0.12.3).

BTW: what happen if you forget to switch and leave "linux_quirk" enabled on MacOS/X or Windows?

Does it work OK on Linux in UAC1 mode?

there seems to be a few minor problems.

First of all, WidgetControl.py (version from git "audio-widget", 2012-04-27) does not recognize the widget in UAC1 mode. Error: "DG8SAQ/MOBO device not found".

I guess this may have to do with the changed IDs? maybe productid=0x03e9 should match with "vendorid1" (0x16c0) instead of vendorid2 (0xfffe) ?

Try this patch, seems to work here.

--- WidgetControl.py~   2012-05-05 10:35:41.951960360 +0200
+++ WidgetControl.py    2012-05-05 12:36:04.699761123 +0200
@@ -33,8 +33,8 @@
 vendorid2    = 0xfffe
 productid1   = 0x05dc
 productid2   = 0x03e8
-productid3   = 0x0007
-productid4   = 0x03e9
+productid3   = 0x03e9
+productid4   = 0x0007
 confignum   = 1
 interfacenum= 0
 timeout     = 1500
@@ -151,7 +151,7 @@
                     founddev = dev
                     foundbus = bus
                     break
-                if (dev.idVendor == vendorid2) & (dev.idProduct == productid3):
+                if (dev.idVendor == vendorid1) & (dev.idProduct == productid3):
                     founddev = dev
                     foundbus = bus
                     break

(patch more complex than strictly required, I have also re-ordered it for purely "esthetic" reasons).

Other problem is that playing a 44.1/16 stream on the ALSA raw device "hw:n,0" fails with error:

play FAIL formats: can't open output file `hw:2,0': select_format error: Operation not permitted

using plughw:2,0 instead works fine.

Same stream in UAC2 mode works fine with both "hw:n,0" and "plughw:n,0" devices.

I guess in UAC2 mode it also accepts 16 bit streams directly while in UAC1 it only accept 32bit ones? Or perhaps it's a matter of what capabilities are known/announced to ALSA? Or is it some intrinsic difference between UAC1 & UAC2?

checking /proc/asound/DG8SAQI2C/stream0 I get the following for UAC1:

www.obdev.at DG8SAQ-I2C at usb-0000:00:1a.1-2, full speed : USB Audio

Playback:
  Status: Stop
  Interface 3
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 4 OUT (ASYNC)
    Rates: 44100, 48000

and for UAC2:

www.obdev.at DG8SAQ-I2C at usb-0000:00:1a.7-4, high speed : USB Audio

Playback:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 2 OUT (ASYNC)
    Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
    Data packet interval: 250 us

I guess that it is the S24_3LE vs S32_LE that makes the difference. Would it be possibile to use S32_LE also in UAC1? or are they standard-mandated formats?

 

[palmito]

BOM for the AB-1.12/1.13?

Is there a BOM for the AB-1.12/1.13 boards? Thanks.

 

[Gluca]

Borges

what size/package are the XOs on the USB-I2S board? Any suggestion for brands/types?

thanks!

 

[alexlee188]

there seems to be a few minor problems.

First of all, WidgetControl.py (version from git "audio-widget", 2012-04-27) does not recognize the widget in UAC1 mode. Error: "DG8SAQ/MOBO device not found".

I guess this may have to do with the changed IDs? maybe productid=0x03e9 should match with "vendorid1" (0x16c0) instead of vendorid2 (0xfffe) ?

Try this patch, seems to work here.

--- WidgetControl.py~   2012-05-05 10:35:41.951960360 +0200
+++ WidgetControl.py    2012-05-05 12:36:04.699761123 +0200
@@ -33,8 +33,8 @@
 vendorid2    = 0xfffe
 productid1   = 0x05dc
 productid2   = 0x03e8
-productid3   = 0x0007
-productid4   = 0x03e9
+productid3   = 0x03e9
+productid4   = 0x0007
 confignum   = 1
 interfacenum= 0
 timeout     = 1500
@@ -151,7 +151,7 @@
                     founddev = dev
                     foundbus = bus
                     break
-                if (dev.idVendor == vendorid2) & (dev.idProduct == productid3):
+                if (dev.idVendor == vendorid1) & (dev.idProduct == productid3):
                     founddev = dev
                     foundbus = bus
                     break

I guess that it is the S24_3LE vs S32_LE that makes the difference. Would it be possibile to use S32_LE also in UAC1? or are they standard-mandated formats?

[/QUOTE]

Hi UnixMan,

I have applied your patch and updated to branch audio-widget.

As for uac1 at 24 bits and uac2 at 32 bits, my suggestion is that if you are running Linux, just use uac2 all the time (with linux quirk applied). uac1 is more for Windows users.

Alex

 

[alexlee188]

Linux Quirk is for LInux only. If you set Linux Quirk under Win or OSX your 88.2/96khz playback will be awful

We are waiting for more evidence/datapoints to be gathered for OTHER uac2 devices such as those based on CMedia and Tenor chips before we can conclusively prove that the problem is with the Linux uac2 driver and not with the AW firmware. The XMOS firmware seems to have figured out a way for Linux compatibility but it is NDA.

Alex

 

[UnixMan]

Hi Alex,

I have applied your patch and updated to branch audio-widget.

I'm glad to have been helpful.

As for uac1 at 24 bits and uac2 at 32 bits, my suggestion is that if you are running Linux, just use uac2 all the time (with linux quirk applied). uac1 is more for Windows users.

yes, of course. Yet there are cases where it may be useful, e.g. on legacy hardware without an USB2 interface (or is UAC2 backward compatible with USB1.1?).

BTW, I was wondering about the reasons behind the format difference (S24_3LE vs S32_LE) mostly for a matter of consistency (not a big deal, of course...).

If you set Linux Quirk under Win or OSX your 88.2/96khz playback will be awful

yup, that's what I was wondering.

We are waiting for more evidence/datapoints to be gathered for OTHER uac2 devices such as those based on CMedia and Tenor chips before we can conclusively prove that the problem is with the Linux uac2 driver and not with the AW firmware.

have the UAC2 ALSA developers been informed about the (possible) problem?

 

[borges]

Is there a BOM for the AB-1.12/1.13 boards? Thanks.

Yepp,

follow my siganture and search for "Download Complete documentation" or go straight to Ab-1.12.13_20120429_xC01_doc.zip - sdr-widget - AB-1.12 / 1.13 updated documentation - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting

Cheers,
Børge

 

[borges]

Borges

what size/package are the XOs on the USB-I2S board? Any suggestion for brands/types?

thanks!

5x7mm pretty standard. 4 pins used. 6 will probably fit mechanically. See my previous post for BOM files with reference to the part number.

NB: XO multiplexing is based on the ENable pin being present on the XO and doing what it's supposed to.

Børge

 

[borges]

As for uac1 at 24 bits and uac2 at 32 bits, my suggestion is that if you are running Linux, just use uac2 all the time (with linux quirk applied). uac1 is more for Windows users.

Alex

Hi Alex,

it would be cool if UAC1 worked on Linux as well. If it doesn't, prehaps that's a sign of dogs being burried deeper in the kernel that what we thought? That's pure speculation, of course.

Børge

 

[UnixMan]

it would be cool if UAC1 worked on Linux as well.

don't worry... it DOES work, perfectly!

There's only a difference in the data format which -with some players- may require the use of the ALSA "plug" interface to do the required conversion (that is, use "plughw:x,0" instead of "hw:x,0").

In UAC2 the required format is the ubiquitous "S32_LE", while in UAC1 mode it requires the less common "S24_3LE" (both are 32bit formats). Some players (such as sox) does not support directly outputting in S24_3LE format, thus the need to let ALSA ("plug" plugin) do the (trivial and lossless) conversion.

 

[Remrk]

Hello everyone,

I recently bought a AB1.1 board from Borges but i have some troubles getting it work in UAC2 under debian/mpd.

Once i switch to UAC2 (using program button) the board is no longer recognized by linux.

here is aplay -l result when UAC2(red led):

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0


Switching to UAC1 ( green led) everything works ok:
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: DG8SAQI2C [DG8SAQ-I2C], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0


i've tried different versions of firmware ( using cracked dfu ) with same result
audio-widget-nik-20111222.elf
audio-widget-nik-2012-01-27.elf
audio-widget-nik-2011-12-26.elf

does anyone have any clue how to fix this ?

thank you

 

[alexlee188]

What is your kernel version?

Uac2 is supported by linux 2.6.38 or later.

Alex

 

[Remrk]

thank you Alex, that did the trick ... now it works

 

[GeorgeBoudreau]

Linux Quirk is for LInux only. If you set Linux Quirk under Win or OSX your 88.2/96khz playback will be awful

We are waiting for more evidence/datapoints to be gathered for OTHER uac2 devices such as those based on CMedia and Tenor chips before we can conclusively prove that the problem is with the Linux uac2 driver and not with the AW firmware. The XMOS firmware seems to have figured out a way for Linux compatibility but it is NDA.

Alex

Hi Alex,
I have not been tracking the Linux problem. Could you give me a nickle tour of the issue. I can give you feedback using the Tenor TE8802 as well as the Cmedia CM6631 evaluation boards.

George

 

[alexlee188]

Hi George,

In Linux, if you play mixed sample rate playlist, the async feedback fails when you

Change from 44.1 or 48 khz to 88.2 or 96 khz.

It will lock if you stop/pause and restart.

Changing from any other rates to any other rates have no problems. Eg 44.1 t to 192 or 96 to 44.1 etc.

The problem will not show up if the whole album is of the same sampling rate.

Alex