[alsa-devel] Roland/Edirol M-16DX
Ricard Wanderlof
ricard.wanderlof at axis.com
Fri Oct 23 10:27:51 CEST 2015
The Roland/Edirol M-16DX is a digital mixer which can also function as a
18 channel capture / 2 channel playback USB 2.0 interface. The device has
been added to quirks-table.h and has been reported as working with one
problem: when playing back there's severe audio distortion at regular
intervals (several seconds), which has been traced to the fact that the
device utilizes the IN endpoint as an implicit feedback channel; see the
output from lsusb -vvv from a 7 year old post by Lasse Kärkkäinen below
for reference:
> Bus 007 Device 025: ID 0582:00c4 Roland Corp.
> 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 0x00c4
> bcdDevice 0.00
> iManufacturer 1 EDIROL
> iProduct 2 M-16DX
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 167
> bNumInterfaces 3
> 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 2
> iInterface 0
> ** UNRECOGNIZED: 06 24 f1 01 00 00
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 1
> bNumEndpoints 1
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 2
> bInterfaceProtocol 2
> iInterface 0
> ** UNRECOGNIZED: 07 24 01 01 00 01 00
> ** UNRECOGNIZED: 0b 24 02 01 02 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 0x0038 1x 56 bytes
> bInterval 1
> 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 2
> bInterfaceProtocol 1
> iInterface 0
> ** UNRECOGNIZED: 07 24 01 07 00 01 00
> ** UNRECOGNIZED: 0b 24 02 01 12 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 0x01f8 1x 504 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 1
> bInterfaceProtocol 3
> iInterface 0
> ** UNRECOGNIZED: 06 24 f1 02 01 01
> 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 2
> 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
On Fri, 14 Nov 2008, Clemens confirmed this in a post:
> James Trevelyan wrote:
> > ...
> > However, what I did notice is that in all circumstances the windows
> > driver was capturing at the same time as playback, even when I was not
> > asking it to record. This suggests to me that the comment in the driver
> > source about synchronising playback to capture has some relevance ...
>
> Indeed. The driver would have to send the data at the exact speed of
> the device's internal clock, and the only way to determine that clock's
> speed is to capture data.
>
> So far I haven't found the time to rewrite the driver to support this
> synchronization mechanism.
I seem to recall reading posts not to long ago that refer to using an
implicit feedback path; my question is, was this in fact implemented,
meaning that a device like the M-16DX should function as expected also for
playback?
/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
More information about the Alsa-devel
mailing list