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:Could you try to rerun the test cases which needed the _LINUX_QUIRK?
(I tried with "linux_quirk" enabled; have to try with it disabled too, just to cross-check).
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!
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
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
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
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
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
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?
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.
(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:
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:
and for UAC2:
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?
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?
there seems to be a few minor problems.Does it work OK on Linux in UAC1 mode?
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
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?
Borges
what size/package are the XOs on the USB-I2S board? Any suggestion for brands/types?
thanks!
what size/package are the XOs on the USB-I2S board? Any suggestion for brands/types?
thanks!
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?
[/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
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
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,
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...).
I'm glad to have been helpful. 🙂I have applied your patch and updated to branch audio-widget.
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?).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.
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...).
yup, that's what I was wondering.If you set Linux Quirk under Win or OSX your 88.2/96khz playback will be awful 🙂
have the UAC2 ALSA developers been informed about the (possible) problem?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.
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
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
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
don't worry... it DOES work, perfectly!it would be cool if UAC1 worked on Linux as well.
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.
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
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
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
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
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
- Home
- Source & Line
- Digital Source
- Open-source USB interface: Audio Widget