Re: Tascam US-122L - Corrupt USB descriptor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux