Open-source USB interface: Audio Widget

Jump to Latest
M

Mjjg

Member
Joined 2007
alexlee188 said:
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
Click to expand...

That worked like a charm. Thanks!
 
B

borges

Member
Joined 2003
UnixMan said:
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).
Click to expand...

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
 
B

borges

Member
Joined 2003
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
 

Attachments

  • DSC_0490.JPG
    DSC_0490.JPG
    93.5 KB · Views: 510
UnixMan

UnixMan

Member
Joined 2005
audiofaidate.org
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?


borges said:
Does it work OK on Linux in UAC1 mode?
Click to expand...
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.
Code: 
--- 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:
Code: 
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:

Code: 
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:
Code: 
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?
 
A

alexlee188

Member
Joined 2011
UnixMan said:
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.
Code: 
--- 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?
Click to expand...

[/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
 
A

alexlee188

Member
Joined 2011
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

UnixMan

Member
Joined 2005
audiofaidate.org
Hi Alex,

alexlee188 said:
I have applied your patch and updated to branch audio-widget.
Click to expand...
I'm glad to have been helpful. :)

alexlee188 said:
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.
Click to expand...
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...).

alexlee188 said:
If you set Linux Quirk under Win or OSX your 88.2/96khz playback will be awful :)
Click to expand...
yup, that's what I was wondering.

alexlee188 said:
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.
Click to expand...
have the UAC2 ALSA developers been informed about the (possible) problem?
 
B

borges

Member
Joined 2003
alexlee188 said:
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
Click to expand...

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

UnixMan

Member
Joined 2005
audiofaidate.org
borges said:
it would be cool if UAC1 worked on Linux as well.
Click to expand...
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.
 
R

Remrk

Member
Joined 2011
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
 
G

GeorgeBoudreau

Member
Joined 2010
alexlee188 said:
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
Click to expand...

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
 
A

alexlee188

Member
Joined 2011
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
 
You must log in or register to reply here.
Top Bottom