[alsa-devel] Tascam US-122L - Corrupt USB descriptor
Hi all, I have been struggling for the past few days to get a Tascam US-122L (USB sound-card/midi interface) working, despite reading numerous forum postings I have only been able to get the midi portion working.
I note that the USB descriptor seems to be corrupt. It declares 2 interfaces, but then describes 3 separate with the same interface number for the last 2... could it be that this is confusing the Linux USB stack?
I have attached a copy of the descriptor and an annotated 'lsusb -vv'.
From my experience with the HID subsystem, they have a mechanism for
patching HID descriptors, is the same possible for the base USB descriptor? Trolling through 'drivers/usb' I didn't see anything... any suggestions?
If this is possible I can try to increase the interface count and renumber the last one.
Cheers, Simon.
PS. For reference the device is: Model No: US-122L Serial: (21)0120xxx Other barcode: 043774021628
Simon Wood wrote:
I have been struggling for the past few days to get a Tascam US-122L (USB sound-card/midi interface) working, despite reading numerous forum postings I have only been able to get the midi portion working.
Does it show up with "aplay -l"?
I note that the USB descriptor seems to be corrupt. It declares 2 interfaces, but then describes 3 separate with the same interface number for the last 2.
The descriptors describe two alternate settings for the same interface. This is a feature, which is required for audio devices.
iManufacturer 1 (error) <------ Here be Errors! iProduct 2 (error) iSerial 3 (error)
It's possible that lsusb does not have the permissions needed to send the messages to ask for the strings. Try running it as root.
Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
On Wed, April 13, 2016 3:01 am, Clemens Ladisch wrote:
Simon Wood wrote:
I have been struggling for the past few days to get a Tascam US-122L (USB sound-card/midi interface) working, despite reading numerous forum postings I have only been able to get the midi portion working.
Does it show up with "aplay -l"?
The card shows up under '/proc/asound/cards', but only as Midi. See attached for full listing.
I note that the USB descriptor seems to be corrupt. It declares 2 interfaces, but then describes 3 separate with the same interface number for the last 2.
The descriptors describe two alternate settings for the same interface. This is a feature, which is required for audio devices.
iManufacturer 1 (error) <------ Here be Errors! iProduct 2 (error) iSerial 3 (error)
It's possible that lsusb does not have the permissions needed to send the messages to ask for the strings. Try running it as root.
Was running as root (on Xubuntu, 2 different machines, different installs).
I note that sometimes this is OK, ie when I do '# echo 0 > /sys/bus/usb/devices/1-2/bConfigurationValue', but then I have no interfaces at all (no midi, no listing).
Can anyone confirm they have a US-122L working on a new kernel. Is the USB descriptor the same as what I'm seeing, perhaps hardware changed at some point. Cheers, Simon
Simon Wood wrote:
The card shows up under '/proc/asound/cards', but only as Midi.
Apparently, there is no PCM device. This driver creates a special hardware-dependent device which is intended to be used with the Jack driver "usb_stream".
It might be possible to use the ALSA "usb_stream" plugin: http://www.alsa-project.org/main/index.php/Matrix:Module-usb-us122l
Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote:
Simon Wood wrote:
The card shows up under '/proc/asound/cards', but only as Midi.
Apparently, there is no PCM device. This driver creates a special hardware-dependent device which is intended to be used with the Jack driver "usb_stream".
It might be possible to use the ALSA "usb_stream" plugin: http://www.alsa-project.org/main/index.php/Matrix:Module-usb-us122l
I have this '.asoundrc' file (made before previous postings), but that does not seem to make a usable card.
I'm expecting that a PCM device should /just/ appear under 'aplay -l', but that is not happening. Perhaps there is a step I am missing, or I am just confused about what qualifies a 'working' US-122L.
Do I need to be using a specific version of (userland) Alsa?
It would be nice to get a 'nod' from a person who has the US-122L workin on their system. But I do appreciate Clemens' help and guidance, Simon.
-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
Simon Wood wrote:
On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote:
Simon Wood wrote:
The card shows up under '/proc/asound/cards', but only as Midi.
Apparently, there is no PCM device. This driver creates a special hardware-dependent device which is intended to be used with the Jack driver "usb_stream".
It might be possible to use the ALSA "usb_stream" plugin: http://www.alsa-project.org/main/index.php/Matrix:Module-usb-us122l
I have this '.asoundrc' file (made before previous postings), but that does not seem to make a usable card.
What error message do you get when you try to use aplay with that device?
I'm expecting that a PCM device should /just/ appear under 'aplay -l'
The driver does not implement such a PCM device.
Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
On Wed, 13 Apr 2016, Simon Wood wrote:
Hi all, I have been struggling for the past few days to get a Tascam US-122L (USB sound-card/midi interface) working, despite reading numerous forum postings I have only been able to get the midi portion working.
I note that the USB descriptor seems to be corrupt. It declares 2 interfaces, but then describes 3 separate with the same interface number for the last 2... could it be that this is confusing the Linux USB stack?
I have attached a copy of the descriptor and an annotated 'lsusb -vv'. ...
My experience of lsusb is that it can get confused and report errors when there in fact aren't any, especially with vendor specific classes which it really can only guess at.
Configuration Descriptor:
00000010 _____ 09 02 48 00 02 01 00 80 f0 ______________ |....H...........|
bLength 9 bDescriptorType 2 wTotalLength 72 bNumInterfaces 2 <------- 2 interfaces bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 480mA Interface Descriptor: <------ that's 1-- 00000010 _________________________________ 09 04 00 00 00 |....H...........| 00000020 ff 00 00 00 ____________________________________ |................| -- bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0
Interface Descriptor: <------ that's 2-- 00000020 ___________ 09 04 01 00 00 ff 00 00 00 ________ |................| -- bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0
Interface Descriptor: <------ that's 3, err wait...-- 00000020 _______________________________________ 09 04 01 |................| 00000030 01 04 ff 00 00 00 ______________________________ |..........N.....| -- bLength 9 bDescriptorType 4 bInterfaceNumber 1 <------ interface duplicate!! bAlternateSetting 1 bNumEndpoints 4
My knowledge of USB is sketchy since I rarely work with it on this level (I was working on some quirks for the Zoom R16 a while ago), but I note that bAlternateSetting is 1, which I think means that the device offers two specific ways of implementing interface no. 1. Actually, IIRC, alternate setting 0 normally means an interface which essentially is disabled, and it would certainly seem so here as the two first interface descriptors have 0 endpoints, whereas the one here has 4.
My wild guess is that this interface 1 / altsetting 1 represents the actual device in normal operation, as has 4 endpoints ...
bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor:... bLength 9 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes ... Endpoint Descriptor: ... bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes ... Endpoint Descriptor: ... bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes ... Endpoint Descriptor: ... bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 4 bRefresh 0 bSynchAddress 0
... the two first of which are the audio interface (which uses isochronous data transfers), and the other two are MIDI (bulk).
I think (but could be wrong so don't take my word for it) it's a bit unusual that both MIDI and audio are represented by a single interface, but it certainly seems to be the case here.
/Ricard
participants (3)
-
Clemens Ladisch -
Ricard Wanderlof -
Simon Wood