[alsa-devel] Roland/Edirol M-16DX
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 Wanderlof wrote:
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,
Yes, for USB Audio 2.0 devices.
meaning that a device like the M-16DX should function as expected also for playback?
There is some bug in the code that should detect such Roland devices.
Regards, Clemens
On Fri, 23 Oct 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
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,
Yes, for USB Audio 2.0 devices.
meaning that a device like the M-16DX should function as expected also for playback?
There is some bug in the code that should detect such Roland devices.
I'm not sure what you mean, is there a bug that fails to detect when it is necessary to use implcit feedback specifically when using Roland devices?
So that when using an M-16DX despite the endpoint desciptor specifying Asynchronous and Implicit feedback it fails to enable that mode?
E.g. something related to the fact that these devices need entries in the quirks table rather than being class compliant?
/Ricard
Ricard Wanderlof wrote:
On Fri, 23 Oct 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
meaning that a device like the M-16DX should function as expected also for playback?
There is some bug in the code that should detect such Roland devices.
I'm not sure what you mean, is there a bug that fails to detect when it is necessary to use implcit feedback specifically when using Roland devices?
Yes.
Regards, Clemens
On Fri, 23 Oct 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
On Fri, 23 Oct 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
meaning that a device like the M-16DX should function as expected also for playback?
There is some bug in the code that should detect such Roland devices.
I'm not sure what you mean, is there a bug that fails to detect when it is necessary to use implcit feedback specifically when using Roland devices?
Yes.
Sounds like something that shouldn't be too hard to fix given a device at hand as well as a couple of hours of debugging time then.
Any more ideas of what the problem is? E.g. because for whatever reason it's not enough to have an entry in the quirks table, or something else completely (like the number of capture and playback channels being different)?
/Ricard
On Fri, 23 Oct 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
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,
Yes, for USB Audio 2.0 devices.
meaning that a device like the M-16DX should function as expected also for playback?
There is some bug in the code that should detect such Roland devices.
I finally got my hands on an M-16DX yesterday, and was preparing myself for some initial research into this problem. Connected the device and used some DAW software (Ardour 3) to record and playback about half a minute of audio. No glitches whatsoever, neither in capture or playback.
So I thought, perhaps a DAW always opens the device for recording and playback and hence there's always a feedback channel open. So I tried just playing back a 7 minute wav file using aplay instead. Again, no glitches in the resulting audio.
More tests are needed - I only used 44.1 kHz sample rate for instance - but have I just been extremely lucky with the sample clocks so they match up precisely (if that even would work), or could the problem have magically fixed itself (ok, more realistically, as a result of something else getting fixed)?
/Ricard
Ricard Wanderlof wrote:
On Fri, 23 Oct 2015, Clemens Ladisch wrote:
There is some bug in the code that should detect such Roland devices.
[...] no glitches in the resulting audio.
have I just been extremely lucky with the sample clocks so they match up precisely (if that even would work), or could the problem have magically fixed itself (ok, more realistically, as a result of something else getting fixed)?
It's possible that the bug does not occur for the M-16DX.
Regards, Clemens
participants (2)
-
Clemens Ladisch
-
Ricard Wanderlof