[alsa-devel] Roland/Edirol M-16DX
This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class. lsusb -vvv is attached below and if you need more information, I can debug the device on Linux and on Vista. 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
Lasse Kärkkäinen wrote:
This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class.
It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it. Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver: { /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } }, HTH Clemens
Sorry about late reply.
It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it.
Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver:
{ /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } },
This allows the device to be detected correctly and capture seems to be working flawlessly. Playback also works, but there is a severe three second distortion in audio once every 30 seconds, at 48 kHz. This seems to be related to the device sampling rate, as the cycle is only 15 seconds when the device is running at 96 kHz.
This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class.
It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it.
Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver:
{ /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } },
Could you add this quirk to the alsa-driver distribution as well? I'm getting tired of patching it myself for every new release :) Note: playback doesn't actually work because it is not properly synchronized. The device also doesn't have any MIDI ports, but maybe that's for remote control of parameters?
At Sun, 15 Mar 2009 04:06:29 +0200, Lasse Kärkkäinen wrote:
This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class.
It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it.
Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver:
{ /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } },
Could you add this quirk to the alsa-driver distribution as well? I'm getting tired of patching it myself for every new release :)
I didn't get any response about the patch, so I couldn't apply it...
Note: playback doesn't actually work because it is not properly synchronized.
... and apparently the patch is buggy.
The device also doesn't have any MIDI ports, but maybe that's for remote control of parameters?
Maybe. Seriously, without the response from testers, the development can never go on. It'd be helpful if you give back the result precisely and soon at the next time... thanks, Takashi
This is still missing in 1.0.20.
This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class. It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it.
Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver:
{ /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } }, Could you add this quirk to the alsa-driver distribution as well? I'm getting tired of patching it myself for every new release :)
I didn't get any response about the patch, so I couldn't apply it...
Perhaps you missed the entire thread that was going on about this in 2008? The one where I reported my results and other people also participated in the analysis.
Seriously, without the response from testers, the development can never go on. It'd be helpful if you give back the result precisely and soon at the next time...
Are you still expecting some feedback? You didn't suggest so in your last message, so I didn't see the need to answer.
At Wed, 27 May 2009 23:49:43 +0300, Lasse Kärkkäinen wrote:
This is still missing in 1.0.20.
This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class. It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it.
Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver:
{ /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } }, Could you add this quirk to the alsa-driver distribution as well? I'm getting tired of patching it myself for every new release :)
I didn't get any response about the patch, so I couldn't apply it...
Perhaps you missed the entire thread that was going on about this in 2008? The one where I reported my results and other people also participated in the analysis.
Wasn't it on alsa-devel ML? I've never seen any reply / follow up on this on ML, at least. (I checked my archive again, and couldn't found any.)
Seriously, without the response from testers, the development can never go on. It'd be helpful if you give back the result precisely and soon at the next time...
Are you still expecting some feedback? You didn't suggest so in your last message, so I didn't see the need to answer.
Well, your previous post says nothing useful, whether the patch works or not, so I assumed that it's just a dead end without any answer. If it's a positive result, then please give the precise information again. No information came out on alsa-devel ML yet, unfortunately (at least it didn't reach to me). thanks, Takashi
Related messages attached. Didn't see any from you, actually. Maybe something you sent didn't reach me? Capture works properly but playback has sync issues. The proper fix (based on what the Windows driver does) would be to capture while playing and to use the capture clock to synchronize playback, but no-one had time to implement that. Hopefully this helps.
At Thu, 28 May 2009 14:03:39 +0300, Lasse Kärkkäinen wrote:
Related messages attached. Didn't see any from you, actually. Maybe something you sent didn't reach me?
Thanks! It seems completely missing in my mailer...
Capture works properly but playback has sync issues. The proper fix (based on what the Windows driver does) would be to capture while playing and to use the capture clock to synchronize playback, but no-one had time to implement that.
OK, the problem is known. The similar problem appears on other devices, AFAIK. So, what should we do now? If you guys are OK to merge even a known-to-be-buggy (but somehow works), I'm going to add it. Takashi
Hopefully this helps.
[2 Liitetty viesti <message/rfc822 (7bit)>] To: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Roland/Edirol M-16DX From: Lasse Kärkkäinen <tronic+8nhy@trn.iki.fi> Delivered-To: tronic@trn.iki.fi Delivered-To: alsa-devel@alsa-project.org Message-ID: <4917B029.7010809@trn.iki.fi> Date: Mon, 10 Nov 2008 05:53:13 +0200 User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 In-Reply-To: <48883AAC.6060101@ladisch.de> List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>, <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe> List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel> List-Post: <mailto:alsa-devel@alsa-project.org> List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help> List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>, <mailto:alsa-devel-request@alsa-project.org?subject=subscribe> Content-Transfer-Encoding: 7bit
Sorry about late reply.
It appears to have most of the audio class descriptors, so it should be possible to tell the driver to just use it.
Please try to add the following entry somewhere in sound/usb/usbquirks.h and to recompile the driver:
{ /* Edirol M-16DX */ USB_DEVICE(0x0582, 0x00c4), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0001, .in_cables = 0x0001 } }, { .ifnum = -1 } } } },
This allows the device to be detected correctly and capture seems to be working flawlessly. Playback also works, but there is a severe three second distortion in audio once every 30 seconds, at 48 kHz. This seems to be related to the device sampling rate, as the cycle is only 15 seconds when the device is running at 96 kHz.
_______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel [3 Liitetty viesti <message/rfc822 (8bit)>] To: "Lasse =?ISO-8859-1?Q?K=E4rkk=E4inen?=" <tronic+cv5n@trn.iki.fi> Cc: alsa-devel@alsa-project.org, clemens@ladisch.de, james@jamestrevelyan.com, timc@wnsp.com Subject: Re: [alsa-devel] Roland/Edirol M-16DX From: James Trevelyan <james@jamestrev.com> Delivered-To: tronic@trn.iki.fi In-Reply-To: <491C6E10.7090308@trn.iki.fi> Date: Fri, 14 Nov 2008 00:55:01 +0000 Message-Id: <1226624101.4836.95.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit
On Thu, 2008-11-13 at 20:12 +0200, Lasse Kärkkäinen wrote:
Has anyone been able to solve the distortion problem yet?
It seems like a broken ringbuffer implementation. The distortion itself seems to be just the signal itself in different phase. I tested this with a 441 Hz (100 samples) sine wave played thru the device and recorded back. The recording is here: http://zi.fi/debug/M16DX-bug.flac
I haven't solved it yet, though I exchanged emails with Tim Camp who reported that he had this working when the device was set to 44.1khz (I haven't had a chance to try this)
I had previously done something similar to Lasse in re-recording a test signal and noticed the same interesting patterns. However, I also did some usb-logging, and when I reassembled the data stream being sent to the device it was as it should be, i.e. uncorrupted, suggesting that the distortion is being caused in the device, and the driver isn't sending a corrupted data stream (though obviously something in the way it is sent is upsetting the device)
I also did some usb-logging under Windows (where it works) and disappointingly couldn't see any obvious difference in the way the data was sent. I played around with things like the size of the urbs in the driver to try to make the raw usb data look the same, but it had no effect.
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 ...
James
[4 Liitetty viesti <message/rfc822 (7bit)>] To: James Trevelyan <james@jamestrev.com> CC: Lasse Kärkkäinen <tronic+cv5n@trn.iki.fi>, alsa-devel@alsa-project.org, james@jamestrevelyan.com, timc@wnsp.com Subject: Re: [alsa-devel] Roland/Edirol M-16DX From: Clemens Ladisch <clemens@ladisch.de> Delivered-To: tronic@trn.iki.fi Message-ID: <491D3300.5050405@ladisch.de> Date: Fri, 14 Nov 2008 09:12:48 +0100 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 In-Reply-To: <1226624101.4836.95.camel@localhost> Content-Transfer-Encoding: 7bit
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.
Best regards, Clemens [5 Liitetty viesti <message/rfc822 (8bit)>] To: James Trevelyan <james@jamestrev.com> Cc: Lasse Kärkkäinen <tronic+cv5n@trn.iki.fi>, alsa-devel@alsa-project.org, clemens@ladisch.de, james@jamestrevelyan.com Subject: Re: [alsa-devel] Roland/Edirol M-16DX From: Tim Camp <timc@wnsp.com> Delivered-To: tronic@trn.iki.fi Reply-To: timc@wnsp.com In-Reply-To: <1226624101.4836.95.camel@localhost> Organization: Dot Com Plus L.L.C. Date: Fri, 14 Nov 2008 08:59:19 -0600 Message-Id: <1226674759.16066.3.camel@operations.dotcom> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit
James,
Reading your email I was struck by something. I also have a digital I/O connected to the mixer from the pc. I wonder if this is allowing the clocks to sync?
Just a thought.
Tim
On Fri, 2008-11-14 at 00:55 +0000, James Trevelyan wrote:
On Thu, 2008-11-13 at 20:12 +0200, Lasse Kärkkäinen wrote:
Has anyone been able to solve the distortion problem yet?
It seems like a broken ringbuffer implementation. The distortion itself seems to be just the signal itself in different phase. I tested this with a 441 Hz (100 samples) sine wave played thru the device and recorded back. The recording is here: http://zi.fi/debug/M16DX-bug.flac
I haven't solved it yet, though I exchanged emails with Tim Camp who reported that he had this working when the device was set to 44.1khz (I haven't had a chance to try this)
I had previously done something similar to Lasse in re-recording a test signal and noticed the same interesting patterns. However, I also did some usb-logging, and when I reassembled the data stream being sent to the device it was as it should be, i.e. uncorrupted, suggesting that the distortion is being caused in the device, and the driver isn't sending a corrupted data stream (though obviously something in the way it is sent is upsetting the device)
I also did some usb-logging under Windows (where it works) and disappointingly couldn't see any obvious difference in the way the data was sent. I played around with things like the size of the urbs in the driver to try to make the raw usb data look the same, but it had no effect.
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 ...
James
So, what should we do now? If you guys are OK to merge even a known-to-be-buggy (but somehow works), I'm going to add it.
Either that or remove playback support so that it doesn't offer broken functionality. I don't see what the broken playback would be good for, except maybe encouraging people to hack ALSA and fix the sync issue. Most importantly make sure that hardware support databases don't mark this device as fully operational.
At Fri, 29 May 2009 13:53:04 +0300, Lasse Kärkkäinen wrote:
So, what should we do now? If you guys are OK to merge even a known-to-be-buggy (but somehow works), I'm going to add it.
Either that or remove playback support so that it doesn't offer broken functionality. I don't see what the broken playback would be good for, except maybe encouraging people to hack ALSA and fix the sync issue.
OK, just merged now to sound git tree with some additional comment. But the playback isn't disabled.
Most importantly make sure that hardware support databases don't mark this device as fully operational.
It's just a Wiki, so feel free to correct it. thanks, Takashi
participants (4)
-
Clemens Ladisch -
Lasse Kärkkäinen -
Lasse Kärkkäinen -
Takashi Iwai