7 Feb
2010
7 Feb
'10
10:35 p.m.
On Sun, 2010-02-07 at 12:42 -0500, Ivica Ico Bukvic wrote:
Clemens,
Sorry for taking this long to get back to this one. I am about to try
this thing out and am wondering if the latest version would be ok to try
out from the same URL
(http://ftp.kernel.org/pub/linux/kernel/people/tiwai/alsa/alsa-driver/)
or do I have to do use one from Dec. 14th 2009?
Please advise.
Best wishes,
Ico
BTW, I just tested the latest snapshot against rt-version of the 2.6.31
kernel (the one that comes with Ubuntu 9.10) with an UVC webcam patch
(there is a bug in the original kernel regarding this), and the ua-101
now does not work at all. dmesg shows proper connects/disconnects of the
hardware but no alsa module is loaded nor is it reflected
in /proc/asound.
I installed the driver from the aforesaid URL with configure/make/make
install. No errors were reported.
I also tried manually loading the module. No errors were reported during
loading of the module yet no new devices showed up.
I tried this both in lo and hi modes for all 8 channels of the
soundcard.
Any ideas?
This definitely looks like a regression of some sort since before the
soundcard was at least properly detected and producing sound.
Best wishes,
Ico
8 Feb
8 Feb
12:24 p.m.
New subject: UA-101
Ivica Ico Bukvic wrote:
On Sun, 2010-02-07 at 12:42 -0500, Ivica Ico Bukvic
wrote:
> am wondering if the latest version would be ok to try out
The driver hasn't changed since then.
dmesg shows proper connects/disconnects of the
hardware but no alsa
module is loaded nor is it reflected in /proc/asound.
The module should have been loaded. What are the messages in the
system log?
I also tried manually loading the module. No errors
were reported during
loading of the module yet no new devices showed up.
There should have been some error message if the driver cannot load.
Did you unload all old sound modules before trying to load the new one?
Regards,
Clemens
1:58 p.m.
New subject: UA-101
-----Original Message-----
From: Clemens Ladisch [mailto:clemens@ladisch.de]
Sent: Monday, February 08, 2010 11:24 AM
To: Ivica Ico Bukvic
Cc: linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] UA-101
Ivica Ico Bukvic wrote:
I don't have it handy but it is typicall USB device detected and registered and
obviously when the device is removed then it is deregistered. The log also differentiates
between the two types of devices (when in lo or hi mode)
On Sun, 2010-02-07 at 12:42 -0500, Ivica Ico
Bukvic wrote:
> am wondering if the latest version would be ok to try out
The driver hasn't changed since then.
dmesg shows proper connects/disconnects of the
hardware but no
alsa
module is loaded nor is it reflected in
/proc/asound.
The module should have been loaded. What are the messages in the
system log? I also tried manually loading the module. No
errors were reported
during
loading of the module yet no new devices showed
up.
There should have been some error message if the driver cannot load.
Did you unload all old sound modules before trying to load the new one?
I rebooted after installing new alsa driver tree.
Are there logs that would be of help in tracing this thing down?
Best wishes,
Ico
2:24 p.m.
New subject: UA-101
Ivica Ico Bukvic wrote:
Strange. There might have been a conflict with the old snd-usb-audio
driver. Is it loaded?
There should
have been some error message if the driver cannot load.
The driver loaded fine. Lsmod listed it and there were no unresolved
symbols.
Did you unload all old sound modules before
trying to load the new one?
I rebooted after installing new alsa driver tree. Are there logs that would be of help in tracing this
thing down?
In theory, there should be. I'll add more logging to the driver ...
Regards,
Clemens
9 Feb
9 Feb
4:33 a.m.
New subject: UA-101
I wrote:
Ivica Ico Bukvic wrote:
Please replace sound/usb/ua101.c with this file:
http://www.alsa-project.org/~clemens/ua101.c
and try again.
Regards,
Clemens
Are there logs that would be of help in tracing
this thing down?
In theory, there should be. I'll add more logging to the driver ... 
13 Feb
13 Feb
4:23 p.m.
New subject: UA-101
Hello Clemens,
Sorry to jump in late to this thread, but is your new UA-101 driver
likely to work for the UA-1000 as well? I'd be very glad to test it with
my UA-1000 if you think it should.
Colin Fletcher
15 Feb
15 Feb
7:32 a.m.
New subject: UA-101
Colin Fletcher wrote:
Sorry to jump in late to this thread, but is your new
UA-101 driver
likely to work for the UA-1000 as well?
This might be possible, if the UA-1000's device IDs are added to the
driver. Please send me the output of "lsusb -v" for this device for all
sample rate settings.
Regards,
Clemens
6:27 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Colin Fletcher wrote:
lsusb -v output for all four sample rate settings attached. I hope it's
helpful.
Thank you very much for your work on this.
Cheers,
Colin.
Bus 001 Device 002: ID 0582:0044 Roland Corp. EDIROL UA-1000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x0582 Roland Corp.
idProduct 0x0044 EDIROL UA-1000
bcdDevice 1.07
iManufacturer 1 EDIROL
iProduct 2 UA-1000
iSerial 3 ZS11854
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 189
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 0b 24 01 00 01 35 00 03 00 01 02
** UNRECOGNIZED: 0c 24 02 01 01 01 00 0a 00 00 00 00
** UNRECOGNIZED: 0c 24 02 02 03 06 00 0c 00 00 00 00
** UNRECOGNIZED: 09 24 03 03 01 01 00 02 00
** UNRECOGNIZED: 09 24 03 04 03 06 00 01 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0c 04 18 01 44 ac 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 37
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
wMaxPacketSize 0x02d0 1x 720 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0a 04 18 01 44 ac 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0230 1x 560 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 003: ID 0582:0044 Roland Corp. EDIROL UA-1000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x0582 Roland Corp.
idProduct 0x0044 EDIROL UA-1000
bcdDevice 1.07
iManufacturer 1 EDIROL
iProduct 2 UA-1000
iSerial 3 ZS11854
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 189
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 0b 24 01 00 01 35 00 03 00 01 02
** UNRECOGNIZED: 0c 24 02 01 01 01 00 0a 00 00 00 00
** UNRECOGNIZED: 0c 24 02 02 03 06 00 0c 00 00 00 00
** UNRECOGNIZED: 09 24 03 03 01 01 00 02 00
** UNRECOGNIZED: 09 24 03 04 03 06 00 01 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0c 04 18 01 80 bb 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 37
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
wMaxPacketSize 0x02d0 1x 720 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0a 04 18 01 80 bb 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0230 1x 560 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 004: ID 0582:0044 Roland Corp. EDIROL UA-1000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x0582 Roland Corp.
idProduct 0x0044 EDIROL UA-1000
bcdDevice 1.07
iManufacturer 1 EDIROL
iProduct 2 UA-1000
iSerial 3 ZS11854
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 189
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 0b 24 01 00 01 35 00 03 00 01 02
** UNRECOGNIZED: 0c 24 02 01 01 01 00 0a 00 00 00 00
** UNRECOGNIZED: 0c 24 02 02 03 06 00 0c 00 00 00 00
** UNRECOGNIZED: 09 24 03 03 01 01 00 02 00
** UNRECOGNIZED: 09 24 03 04 03 06 00 01 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0c 04 18 01 88 58 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 37
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
wMaxPacketSize 0x02d0 1x 720 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0a 04 18 01 88 58 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0230 1x 560 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 005: ID 0582:0044 Roland Corp. EDIROL UA-1000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x0582 Roland Corp.
idProduct 0x0044 EDIROL UA-1000
bcdDevice 1.07
iManufacturer 1 EDIROL
iProduct 2 UA-1000
iSerial 3 ZS11854
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 189
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
** UNRECOGNIZED: 0b 24 01 00 01 35 00 03 00 01 02
** UNRECOGNIZED: 0c 24 02 01 01 01 00 0a 00 00 00 00
** UNRECOGNIZED: 0c 24 02 02 03 06 00 0c 00 00 00 00
** UNRECOGNIZED: 09 24 03 03 01 01 00 02 00
** UNRECOGNIZED: 09 24 03 04 03 06 00 01 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0c 04 18 01 00 77 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 37
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
wMaxPacketSize 0x02d0 1x 720 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
** UNRECOGNIZED: 0b 24 02 01 0a 04 18 01 00 77 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0230 1x 560 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Sorry to jump in late to this thread, but is your
new UA-101 driver
likely to work for the UA-1000 as well?
This might be possible, if the UA-1000's device IDs are added to the
driver. Please send me the output of "lsusb -v" for this device for all
sample rate settings.
17 Feb
17 Feb
4:57 a.m.
New subject: UA-101
Colin Fletcher wrote:
Clemens Ladisch wrote:
Okay, it should work. Please replace your ua101.c with this one:
http://www.alsa-project.org/~clemens/ua101.c
Regards,
Clemens
Colin Fletcher wrote:
lsusb -v output for all four sample rate settings attached. I hope it's
helpful. Sorry to jump in late to this thread, but is your
new UA-101 driver
likely to work for the UA-1000 as well?
This might be possible, if the UA-1000's device IDs are added to the
driver. Please send me the output of "lsusb -v" for this device for all
sample rate settings.
1:24 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Colin Fletcher wrote:
Thank you for looking at this.
I replaced the version of ua101.c in alsa-driver-1.0.22.1 with this one,
and I get:
make -C /lib/modules/2.6.32.7-b43-force-pio/source
SUBDIRS=/home/colinf/src/alsa/alsa-driver-1.0.22.1 CPP="gcc -E"
CC="gcc" modules
make[1]: Entering directory `/home/colinf/src/linux/linux-2.6'
CC [M] /home/colinf/src/alsa/alsa-driver-1.0.22.1/usb/ua101.o
In file included from
/home/colinf/src/alsa/alsa-driver-1.0.22.1/usb/ua101.c:2:
/home/colinf/src/alsa/alsa-driver-1.0.22.1/usb/../alsa-kernel/usb/ua101.c:914:
error: ‘snd_pcm_lib_mmap_vmalloc’ undeclared here (not in a function)
/home/colinf/src/alsa/alsa-driver-1.0.22.1/usb/../alsa-kernel/usb/ua101.c:
In function ‘ua101_card_free’:
/home/colinf/src/alsa/alsa-driver-1.0.22.1/usb/../alsa-kernel/usb/ua101.c:1187:
warning: unused variable ‘ua’
make[3]: *** [/home/colinf/src/alsa/alsa-driver-1.0.22.1/usb/ua101.o]
Error 1
make[2]: *** [/home/colinf/src/alsa/alsa-driver-1.0.22.1/usb] Error 2
make[1]: *** [_module_/home/colinf/src/alsa/alsa-driver-1.0.22.1] Error 2
make[1]: Leaving directory `/home/colinf/src/linux/linux-2.6'
make: *** [compile] Error 2
If I comment out the references to snd_pcm_lib_mmap_vmalloc on lines 914
and 927, make && sudo make install in alsa-driver-1.0.22.1 run to
completion, but when I connect the UA-1000, I get the following in
/var/log/messages:
Feb 17 17:11:50 colinf-laptop kernel: [ 2141.695322] snd_usb_lib:
disagrees about version of symbol snd_rawmidi_receive
Feb 17 17:11:50 colinf-laptop kernel: [ 2141.695326] snd_usb_lib:
Unknown symbol snd_rawmidi_receive
Feb 17 17:11:50 colinf-laptop kernel: [ 2141.695454] snd_usb_lib:
disagrees about version of symbol snd_rawmidi_transmit_empty
Feb 17 17:11:50 colinf-laptop kernel: [ 2141.695456] snd_usb_lib:
Unknown symbol snd_rawmidi_transmit_empty
[and so on for about 60 different snd_* symbols ]
I have kernel 2.6.32.8 (built from kernel.org source). Should I be using
a different kernel, or a different version of alsa-driver, or have I
made some other mistake?
Cheers,
Colin.
Clemens Ladisch wrote:
Okay, it should work. Please replace your ua101.c with this one:
http://www.alsa-project.org/~clemens/ua101.c Colin Fletcher wrote:
lsusb -v output for all four sample rate settings attached.
I hope it's
helpful. Sorry to jump in late to this thread, but is your
new UA-101 driver
likely to work for the UA-1000 as well?
This might be possible, if the
UA-1000's device IDs are added to the
driver. Please send me the output of "lsusb -v" for this device for all
sample rate settings.
2:22 p.m.
New subject: UA-101
Colin Fletcher wrote:
Clemens Ladisch wrote:
Sorry, this function is defined only in the latest development ALSA
drivers.
Okay, it should work. Please replace your
ua101.c with this one:
http://www.alsa-project.org/~clemens/ua101.c
Thank you for looking at this.
I replaced the version of ua101.c in alsa-driver-1.0.22.1 with this one,
and I get:
...
ua101.c:914: error: ‘snd_pcm_lib_mmap_vmalloc’ undeclared here (not in a function)
If I comment out the references to
snd_pcm_lib_mmap_vmalloc on lines 914
and 927,
This is actually the correct remedy for an older ALSA. :)
make && sudo make install in
alsa-driver-1.0.22.1 run to
completion, but when I connect the UA-1000, I get the following in
/var/log/messages:
Feb 17 17:11:50 colinf-laptop kernel: [ 2141.695322] snd_usb_lib:
disagrees about version of symbol snd_rawmidi_receive
Unload all old sound modules before loading the new ones, or just reboot.
HTH
Clemens
3:06 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Yes, sorry, I realised this after I hit 'send'. Anyway, it all
seems to work after a reboot, but I have a feeling it might still be
using the snd-usb-audio driver rather than the snd-ua101.
Should the create_ua1000_quirk() function be removed from usbaudio.c too?
Cheers,
Colin.
Colin Fletcher wrote:
Good: I hoped so.
Clemens Ladisch wrote:
Sorry, this function is defined only in the latest development ALSA
drivers.
Okay, it should work. Please replace your
ua101.c with this one:
http://www.alsa-project.org/~clemens/ua101.c
Thank you for looking at this.
I replaced the version of ua101.c in alsa-driver-1.0.22.1 with this one,
and I get:
...
ua101.c:914: error: ‘snd_pcm_lib_mmap_vmalloc’ undeclared here (not in a function) If I comment out the references to
snd_pcm_lib_mmap_vmalloc on lines 914
and 927,
This is actually the correct remedy for an older ALSA. :) make
&& sudo make install in alsa-driver-1.0.22.1 run to
completion, but when I connect the UA-1000, I get the following in
/var/log/messages:
Feb 17 17:11:50 colinf-laptop kernel: [ 2141.695322] snd_usb_lib:
disagrees about version of symbol snd_rawmidi_receive
Unload all old sound modules before loading the new ones, or just reboot.
18 Feb
18 Feb
4:32 a.m.
New subject: UA-101
Colin Fletcher wrote:
Anyway, it all
seems to work after a reboot, but I have a feeling it might still be
using the snd-usb-audio driver rather than the snd-ua101.
Does the entry in /proc/asound/cards show the serial number?
Should the create_ua1000_quirk() function be removed
from usbaudio.c too?
In theory yes, but it suffices to remove the entry from usbquirks.h.
Or just unload snd-usb-audio.
Regards,
Clemens
7:57 p.m.
New subject: UA-101
Clemens,
I have something quite odd with my snapshot of alsa. I downloaded
20100207 snapshot and the ua101.c only had 2 lines in it which may
explain why it did not build for me. After that I replaced it with the
one you posted in your URL the other day but even now it does not build
explicitly ua101 module. Is its inclusion supposed to be adjusted in the
makefile? If so where?
Also, is there a better place to retrieve the Alsa snapshot from which
reflects this?
Finally, is the module supposed to be ua101 or is this still part of the
usb-snd-audio module?
Please advise.
Best wishes,
Ico
19 Feb
19 Feb
3:36 a.m.
New subject: UA-101
Ivica Ico Bukvic wrote:
I have something quite odd with my snapshot of alsa. I
downloaded
20100207 snapshot and the ua101.c only had 2 lines in it
This is the build stub for the driver package; the actual file is not
alsa-driver-xxx/usb/ua101.c but alsa-driver-xxx/alsa-kernel/usb/ua101.c
it does not build explicitly ua101 module.
Sorry, I didn't mention that you need kernel 2.6.32 or later.
Regards,
Clemens
6:22 a.m.
New subject: UA-101
Clemens Ladisch wrote:
Colin Fletcher wrote:
OK, I removed the quirk for usbquirks.h. Now, on plugging in the UA-1000
I get "BUG: unable to handle kernel NULL pointer dereference at
00000004", and I have to power off to reset the computer.
I took a picture of the backtrace, which I've uploaded to:
http://www.starlingaudio.co.uk/misc/201002191461.jpg
I hope this is useful info for you.
Cheers,
Colin.
Should the create_ua1000_quirk() function be
removed from usbaudio.c too?
In theory yes, but it suffices to remove the entry from usbquirks.h. 
10:28 a.m.
New subject: UA-101
Colin Fletcher wrote:
OK, I removed the quirk for usbquirks.h. Now, on
plugging in the UA-1000
I get "BUG: unable to handle kernel NULL pointer dereference at
00000004", and I have to power off to reset the computer.
I took a picture of the backtrace, which I've uploaded to:
http://www.starlingaudio.co.uk/misc/201002191461.jpg
I hope this is useful info for you.
This looks like a bug in the EHCI driver; I'll see if I can reproduce
this.
Please try without PulseAudio (which isn't really at fault here).
Regards,
Clemens
11:29 a.m.
New subject: UA-101
Clemens Ladisch wrote:
Colin Fletcher wrote:
That works a bit better: the module loads, and I can start jackd using
the card. I suspect it's not passing audio correctly, because jdelay
produced nonsensical-looking results, but I haven't investigated that
any further yet.
Stopping jackd provokes a similar-looking bug to before: partial
backtrace (the top scrolled off my screen) at
http://www.starlingaudio.co.uk/misc/201002191462.jpg
Cheers,
Colin.
OK, I removed the quirk for usbquirks.h. Now, on
plugging in the UA-1000
I get "BUG: unable to handle kernel NULL pointer dereference at
00000004", and I have to power off to reset the computer.
I took a picture of the backtrace, which I've uploaded to:
http://www.starlingaudio.co.uk/misc/201002191461.jpg
I hope this is useful info for you.
This looks like a bug in the EHCI driver; I'll see if I can reproduce
this.
Please try without PulseAudio (which isn't really at fault here). 
1:49 p.m.
New subject: UA-101
Colin Fletcher wrote:
Stopping jackd provokes a similar-looking bug to
before: partial
backtrace (the top scrolled off my screen) at
http://www.starlingaudio.co.uk/misc/201002191462.jpg
This is exactly the same bug. Apparently, it happens whenever the audio
device is closed. Just don't stop Jack. ;-)
Regards,
Clemens
1:58 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Colin Fletcher wrote:
I'll test some more tomorrow. Do you think the bug is likely to be a
simple one to fix?
Cheers,
Colin.
Stopping jackd provokes a similar-looking bug to
before: partial
backtrace (the top scrolled off my screen) at
http://www.starlingaudio.co.uk/misc/201002191462.jpg
This is exactly the same bug. Apparently, it happens whenever the audio
device is closed. Just don't stop Jack. ;-)
20 Feb
20 Feb
3:18 p.m.
New subject: UA-101
Colin Fletcher wrote:
I'll test some more tomorrow.
Replying to myself:
Playback sounds OK to my ears (at least at 44.1kHz).
I get lines like this in my syslog:
Feb 20 19:16:15 colinf-laptop kernel: [ 5053.276720] capture rate: 44101
44100 44101 44100 44101 44100 44100 44100 44101 44100
Feb 20 19:16:25 colinf-laptop kernel: [ 5063.277137] capture rate: 44101
44100 44101 44100 44100 44101 44100 44100 44101 44100
which I assume mean all is well.
Capture is very noisy: there's a white noise-like signal superimposed on
the captured sound, and sounding like its amplitude is modulated by the
captured signal.
Do you think it might be worth trying a 2.6.33 series kernel to see if
the EHCI driver bug has been fixed upstream?
Cheers,
Colin.
21 Feb
21 Feb
1:30 p.m.
New subject: UA-101
Colin Fletcher wrote:
Playback sounds OK to my ears (at least at 44.1kHz).
I've now tried 48kHz sample rate as well, and this also sounds right on
playback.
Capture is very noisy: there's a white noise-like
signal superimposed on
the captured sound, and sounding like its amplitude is modulated by the
captured signal.
I played back a 440Hz sine wave and recorded it back in. Results for
44.1kHz are here:
http://www.starlingaudio.co.uk/misc/audiofiles.tar.bz2
The signal starts at silence, and fades up to 0dB over 10 seconds.
Looking at the waveforms, it appears that sections 4 or 5 samples long
are "shuffled" out of order in the captured signal.
I tried the same thing at 48kHz, and the noise on the captured signal
was similar, but more "metallic" sounding, presumably because 48kHz is a
multiple of the USB rate so the "shuffled" sections are of more constant
length.
I hope this is useful feedback.
Cheers,
Colin.
23 Feb
23 Feb
8:15 a.m.
New subject: UA-101
Colin Fletcher wrote:
Colin Fletcher wrote:
Thanks. This means that the capture problem is not related with the
sample clock synchronization.
Playback sounds OK to my ears (at least at
44.1kHz).
I've now tried 48kHz sample rate as well, and this also sounds right on
playback. I played back a 440Hz sine wave and recorded it back
in. Results for
44.1kHz are here:
http://www.starlingaudio.co.uk/misc/audiofiles.tar.bz2
There is no recorded data.
Floating-point samples (as used by e.g. Jack) don't show what bits the
device sent; please use arecord, like this:
arecord -D hw:UA1000 -f S32 -r 44100 -c 10 something.wav
I'm still investigating the crash.
Regards,
Clemens
1:54 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Colin Fletcher wrote:
Oops, I'm really sorry: I added the wrong file to the archive. If it's
any use, the file I actually intended to upload (still 32-bit floats
recorded through Jack, I'm afraid) is here:
http://www.starlingaudio.co.uk/misc/received.wav.tar.bz2
I played back a 440Hz sine wave and recorded it
back in. Results for
44.1kHz are here:
http://www.starlingaudio.co.uk/misc/audiofiles.tar.bz2
There is no recorded data. Floating-point samples (as used by e.g. Jack)
don't show what bits the
device sent; please use arecord, like this:
arecord -D hw:UA1000 -f S32 -r 44100 -c 10 something.wav
Here's one seconds worth of 12 channels recorded with arecord, with
440Hz of (approximately) sine wave in channels 1, 2, 3 & 4, and silence
in the rest:
http://www.starlingaudio.co.uk/misc/arecord-test.wav.tar.bz2
(There are 12 capture channels on the UA-1000: 1-8 are analogue inputs,
9-10 are the SP-DIF, and 11-12 are a mix of the output signals.)
I hope this is more helpful than my previous try.
Cheers,
Colin.
3:12 p.m.
New subject: UA-101
On Tue, Feb 23, 2010 at 05:54:46PM +0000, Colin Fletcher wrote:
Here's one seconds worth of 12 channels recorded
with arecord, with
440Hz of (approximately) sine wave in channels 1, 2, 3 & 4, and silence
in the rest:
http://www.starlingaudio.co.uk/misc/arecord-test.wav.tar.bz2
Yuk ! It looks indeed as a transposition of small blocks
of samples, and it's synchronous on all four channels.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
24 Feb
24 Feb
8:36 a.m.
New subject: UA-101
Colin Fletcher wrote:
Colin Fletcher wrote:
USB high speed uses 8000 frames per second, so one packet contains
about 5.5 (44100/8000) samples. It's obvious that the USB packets are
exchanged somehow.
Please try the patch below, or download the new ua101.c from
<http://www.alsa-project.org/~clemens/ua101.c>. This will log the
sequence in which the first 50 USB packets are received, but it won't
fix anything.
Since the kernel crash happens when resetting the capture interface,
there is a possibilty that these bugs are related, probably due to some
corruption of the EHCI data structures. Trying a 2.6.33 kernel might
help, although I don't know of any change that could affect this.
Regards,
Clemens
--- alsa-kernel/sound/usb/ua101.c.orig Tue Feb 16 21:47:56 2010
+++ alsa-kernel/sound/usb/ua101.c Wed Feb 24 13:28:57 2010
@@ -367,6 +367,14 @@
unsigned int frames, write_ptr;
bool do_period_elapsed;
int err;
+ static int ccc = 0;
+
+ if (ccc < 50) {
+ ccc++;
+ for (err = 0; err < stream->queue_length; ++err)
+ if (urb == &stream->urbs[err]->urb)
+ printk(KERN_DEBUG "completed URB %d\n", err);
+ }
if (unlikely(urb->status == -ENOENT || /* unlinked */
urb->status == -ENODEV || /* device removed */
@@ -465,6 +473,8 @@
err, usb_error_string(err));
return err;
}
+ if (stream == &ua->capture)
+ printk(KERN_DEBUG "submitted URB %u\n", i);
}
return 0;
}
Capture is very noisy: there's a white
noise-like signal superimposed on
the captured sound, and sounding like its amplitude is modulated by the
captured signal.
Looking at the waveforms, it appears that sections 4 or 5 samples long
are "shuffled" out of order in the captured signal.
3:40 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Please try the patch below, or download the new
ua101.c from
<http://www.alsa-project.org/~clemens/ua101.c>. This will log the
sequence in which the first 50 USB packets are received, but it won't
fix anything.
Attached the results of plugging in the UA-1000 and recording one second
of 12 channels of audio from it, exactly as I made the 12-channel file I
uploaded yesterday.
Since the kernel crash happens when resetting the
capture interface,
there is a possibilty that these bugs are related, probably due to some
corruption of the EHCI data structures. Trying a 2.6.33 kernel might
help, although I don't know of any change that could affect this.
I've updated to kernel 2.6.32.9 today and still get the same crash; I
haven't tried a 2.6.33 kernel yet.
Cheers,
Colin.
25 Feb
25 Feb
4:51 a.m.
New subject: UA-101
Colin Fletcher wrote:
Clemens Ladisch wrote:
| Feb 24 19:20:21 colinf-laptop kernel: [ 338.470986] completed URB 1
| Feb 24 19:20:21 colinf-laptop kernel: [ 338.471021] completed URB 0
| Feb 24 19:20:21 colinf-laptop kernel: [ 338.471216] completed URB 3
| Feb 24 19:20:21 colinf-laptop kernel: [ 338.471239] completed URB 2
| Feb 24 19:20:21 colinf-laptop kernel: [ 338.471441] completed URB 4
| Feb 24 19:20:21 colinf-laptop kernel: [ 338.471468] completed URB 5
| ...
This is obviously the wrong order.
Please try the patch below, or download the new
ua101.c from
<http://www.alsa-project.org/~clemens/ua101.c>. This will log the
sequence in which the first 50 USB packets are received, but it won't
fix anything.
Attached the results of plugging in the UA-1000 and recording I've updated to kernel 2.6.32.9 today and still
get the same crash; I
haven't tried a 2.6.33 kernel yet.
Please try toggling the kernel config option CONFIG_USB_EHCI_TT_NEWSCHED
("Improved Transaction Translator scheduling (EXPERIMENTAL)") of the
EHCI driver. What value does it have at the moment?
Regards,
Clemens
7:48 a.m.
New subject: UA-101
Clemens Ladisch wrote:
Please try toggling the kernel config option
CONFIG_USB_EHCI_TT_NEWSCHED
("Improved Transaction Translator scheduling (EXPERIMENTAL)") of the
EHCI driver. What value does it have at the moment?
$ grep CONFIG_USB_EHCI_TT_NEWSCHED .config
CONFIG_USB_EHCI_TT_NEWSCHED=y
I've recompiled 2.6.32.9 with it unset now, but I probably won't have a
chance to test it until tomorrow morning. I'll let you know what I find.
Cheers,
Colin.
26 Feb
26 Feb
1:15 p.m.
New subject: UA-101
Clemens Ladisch wrote:
Please try toggling the kernel config option
CONFIG_USB_EHCI_TT_NEWSCHED
("Improved Transaction Translator scheduling (EXPERIMENTAL)") of the
EHCI driver.
Here are some more logs.
ua-1000-ehci-oldsched.log is the result with CONFIG_USB_EHCI_TT_NEWSCHED
not set: the URBs still complete out-of-order.
Out of curiousity, because I have a dual-core CPU, I also tried booting
the CONFIG_USB_EHCI_TT_NEWSCHED=y kernel with maxcpus=0
(ua-1000-ehci-newsched-maxcpus-0.log) and maxcpus=1
(ua-1000-ehci-newsched-maxcpus-1.log), to see what would happen.
Curiously, maxcpus=0 shows the URBs completing in order, except that
submitting URB 20 is delayed until after 0-19 have completed. maxcpus=1
has the URBs out-of-order. I don't know what to conclude from this;
maybe it makes some sense to you?
Is there anything else you'd like me to try? Or anything else you might
need to know about my system?
Is there a more appropriate list for this, or are we still on-topic for LAU?
Cheers,
Colin.
1:39 p.m.
New subject: UA-101
Colin Fletcher wrote:
ua-1000-ehci-oldsched.log is the result with
CONFIG_USB_EHCI_TT_NEWSCHED
not set: the URBs still complete out-of-order.
Out of curiousity, because I have a dual-core CPU, I also tried booting
the CONFIG_USB_EHCI_TT_NEWSCHED=y kernel with maxcpus=0
(ua-1000-ehci-newsched-maxcpus-0.log) and maxcpus=1
(ua-1000-ehci-newsched-maxcpus-1.log), to see what would happen.
Curiously, maxcpus=0 shows the URBs completing in order, except that
submitting URB 20 is delayed until after 0-19 have completed. maxcpus=1
has the URBs out-of-order. I don't know what to conclude from this;
maybe it makes some sense to you?
With maxcpus=0, several URBs are completed out of order after timestamp
203.58, and they should not complete at that time but ten milliseconds
later.
As far as I can see, none of these changes make much of a difference.
(The TT scheduler should affect only low or full speed transfers.)
Is there anything else you'd like me to try?
Please change line 376 to
printk(KERN_DEBUG "completed URB %d, status: %d, bytes: %u\n", err,
urb->status, urb->iso_frame_desc[0].actual_length);
and show the logs for both maxcpus=1 and multiple cores.
Can you try this on any other computer?
Or anything else you might need to know about my
system?
Is this really an unpatched kernel.org kernel?
What USB controller do you have (see lspci)?
Is there a more appropriate list for this, or are we
still on-topic for LAU?
I'm not sure if this is a problem with the EHCI driver or your USB
controller, but both would be appropriate for the linux-usb list.
Regards,
Clemens
8 Feb
8 Feb
12:34 p.m.
New subject: UA-101
On Sun, 7 Feb 2010, Ivica Ico Bukvic wrote:
BTW, I just tested the latest snapshot against
rt-version of the 2.6.31
kernel (the one that comes with Ubuntu 9.10) with an UVC webcam patch
(there is a bug in the original kernel regarding this), and the ua-101
now does not work at all. dmesg shows proper connects/disconnects of the
Does the UA-101 work OK with the unpatched kernel?
-gabriel
5385
days inactive
5404
days old
linux-audio-user@lists.linuxaudio.org
31 comments
5 participants
participants (5)
-
Clemens Ladisch -
Colin Fletcher -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Ivica Ico Bukvic