* Roland/Edirol M-16DX
@ 2008-07-24 2:17 Lasse Kärkkäinen
2008-07-24 2:38 ` Jon Smirl
0 siblings, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2008-07-24 2:17 UTC (permalink / raw)
To: alsa-devel
Repost, as I got no responses to the original.
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2008-07-24 2:17 Roland/Edirol M-16DX Lasse Kärkkäinen
@ 2008-07-24 2:38 ` Jon Smirl
0 siblings, 0 replies; 21+ messages in thread
From: Jon Smirl @ 2008-07-24 2:38 UTC (permalink / raw)
To: Lasse Kärkkäinen; +Cc: alsa-devel
It takes a lot of effort to reverse engineer a device without any
documentation. It would be much easier if you got Roland to give you a
detailed spec on the protocol. Ask their customer support for Linux
drivers. Tell them you'll write a driver if you get the specs and then
send the specs to GregKH's free Linux drivers group.
Once you get a spec it shouldn't be too hard to write a driver unless
they did something really crazy.
Open then box up and look at the chip labels. They could just be
obscuring something that already has a driver by changing the USB
profile.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2015-11-12 7:58 ` Ricard Wanderlof
@ 2015-11-12 12:38 ` Clemens Ladisch
0 siblings, 0 replies; 21+ messages in thread
From: Clemens Ladisch @ 2015-11-12 12:38 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2015-10-23 11:01 ` Clemens Ladisch
2015-10-23 14:44 ` Ricard Wanderlof
@ 2015-11-12 7:58 ` Ricard Wanderlof
2015-11-12 12:38 ` Clemens Ladisch
1 sibling, 1 reply; 21+ messages in thread
From: Ricard Wanderlof @ 2015-11-12 7:58 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
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 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2015-10-23 15:08 ` Clemens Ladisch
@ 2015-10-24 5:51 ` Ricard Wanderlof
0 siblings, 0 replies; 21+ messages in thread
From: Ricard Wanderlof @ 2015-10-24 5:51 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
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
--
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2015-10-23 14:44 ` Ricard Wanderlof
@ 2015-10-23 15:08 ` Clemens Ladisch
2015-10-24 5:51 ` Ricard Wanderlof
0 siblings, 1 reply; 21+ messages in thread
From: Clemens Ladisch @ 2015-10-23 15:08 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: Ricard Wanderlöf, alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2015-10-23 11:01 ` Clemens Ladisch
@ 2015-10-23 14:44 ` Ricard Wanderlof
2015-10-23 15:08 ` Clemens Ladisch
2015-11-12 7:58 ` Ricard Wanderlof
1 sibling, 1 reply; 21+ messages in thread
From: Ricard Wanderlof @ 2015-10-23 14:44 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Ricard Wanderlöf, alsa-devel
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 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2015-10-23 8:27 Ricard Wanderlof
@ 2015-10-23 11:01 ` Clemens Ladisch
2015-10-23 14:44 ` Ricard Wanderlof
2015-11-12 7:58 ` Ricard Wanderlof
0 siblings, 2 replies; 21+ messages in thread
From: Clemens Ladisch @ 2015-10-23 11:01 UTC (permalink / raw)
To: Ricard Wanderlof, alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Roland/Edirol M-16DX
@ 2015-10-23 8:27 Ricard Wanderlof
2015-10-23 11:01 ` Clemens Ladisch
0 siblings, 1 reply; 21+ messages in thread
From: Ricard Wanderlof @ 2015-10-23 8:27 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-05-29 10:53 ` Lasse Kärkkäinen
@ 2009-06-01 9:11 ` Takashi Iwai
0 siblings, 0 replies; 21+ messages in thread
From: Takashi Iwai @ 2009-06-01 9:11 UTC (permalink / raw)
To: Lasse Kärkkäinen; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-05-29 6:35 ` Takashi Iwai
@ 2009-05-29 10:53 ` Lasse Kärkkäinen
2009-06-01 9:11 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2009-05-29 10:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
> 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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-05-28 11:03 ` Lasse Kärkkäinen
@ 2009-05-29 6:35 ` Takashi Iwai
2009-05-29 10:53 ` Lasse Kärkkäinen
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2009-05-29 6:35 UTC (permalink / raw)
To: Lasse Kärkkäinen; +Cc: alsa-devel
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
> >
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-05-27 21:08 ` Takashi Iwai
@ 2009-05-28 11:03 ` Lasse Kärkkäinen
2009-05-29 6:35 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2009-05-28 11:03 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
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.
[-- Attachment #2: Liitetty viesti --]
[-- Type: message/rfc822, Size: 4452 bytes --]
From: "Lasse Kärkkäinen" <tronic+8nhy@trn.iki.fi>
To: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Roland/Edirol M-16DX
Date: Mon, 10 Nov 2008 05:53:13 +0200
Message-ID: <4917B029.7010809@trn.iki.fi>
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
[-- Attachment #3: Liitetty viesti --]
[-- Type: message/rfc822, Size: 2945 bytes --]
From: James Trevelyan <james@jamestrev.com>
To: "Lasse Kärkkäinen" <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
Date: Fri, 14 Nov 2008 00:55:01 +0000
Message-ID: <1226624101.4836.95.camel@localhost>
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
[-- Attachment #4: Liitetty viesti --]
[-- Type: message/rfc822, Size: 2365 bytes --]
From: Clemens Ladisch <clemens@ladisch.de>
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
Date: Fri, 14 Nov 2008 09:12:48 +0100
Message-ID: <491D3300.5050405@ladisch.de>
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
[-- Attachment #5: Liitetty viesti --]
[-- Type: message/rfc822, Size: 3408 bytes --]
From: Tim Camp <timc@wnsp.com>
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
Date: Fri, 14 Nov 2008 08:59:19 -0600
Message-ID: <1226674759.16066.3.camel@operations.dotcom>
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
>
[-- Attachment #6: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-05-27 20:49 ` Lasse Kärkkäinen
@ 2009-05-27 21:08 ` Takashi Iwai
2009-05-28 11:03 ` Lasse Kärkkäinen
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2009-05-27 21:08 UTC (permalink / raw)
To: Lasse Kärkkäinen; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-03-16 7:04 ` Takashi Iwai
@ 2009-05-27 20:49 ` Lasse Kärkkäinen
2009-05-27 21:08 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2009-05-27 20:49 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2009-03-15 2:06 ` Lasse Kärkkäinen
@ 2009-03-16 7:04 ` Takashi Iwai
2009-05-27 20:49 ` Lasse Kärkkäinen
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2009-03-16 7:04 UTC (permalink / raw)
To: Lasse Kärkkäinen
Cc: alsa-devel, Clemens Ladisch, Lasse Kärkkäinen
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2008-07-24 8:17 ` Clemens Ladisch
2008-11-10 3:53 ` Lasse Kärkkäinen
@ 2009-03-15 2:06 ` Lasse Kärkkäinen
2009-03-16 7:04 ` Takashi Iwai
1 sibling, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2009-03-15 2:06 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel, Lasse Kärkkäinen
>> 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?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
[not found] ` <1226624101.4836.95.camel@localhost>
@ 2008-11-14 8:12 ` Clemens Ladisch
0 siblings, 0 replies; 21+ messages in thread
From: Clemens Ladisch @ 2008-11-14 8:12 UTC (permalink / raw)
To: James Trevelyan; +Cc: Lasse Kärkkäinen, james, alsa-devel, timc
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2008-07-24 8:17 ` Clemens Ladisch
@ 2008-11-10 3:53 ` Lasse Kärkkäinen
[not found] ` <491C6E10.7090308@trn.iki.fi>
2009-03-15 2:06 ` Lasse Kärkkäinen
1 sibling, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2008-11-10 3:53 UTC (permalink / raw)
To: alsa-devel
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roland/Edirol M-16DX
2008-07-17 9:29 Lasse Kärkkäinen
@ 2008-07-24 8:17 ` Clemens Ladisch
2008-11-10 3:53 ` Lasse Kärkkäinen
2009-03-15 2:06 ` Lasse Kärkkäinen
0 siblings, 2 replies; 21+ messages in thread
From: Clemens Ladisch @ 2008-07-24 8:17 UTC (permalink / raw)
To: Lasse Kärkkäinen; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Roland/Edirol M-16DX
@ 2008-07-17 9:29 Lasse Kärkkäinen
2008-07-24 8:17 ` Clemens Ladisch
0 siblings, 1 reply; 21+ messages in thread
From: Lasse Kärkkäinen @ 2008-07-17 9:29 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2015-11-12 12:38 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-24 2:17 Roland/Edirol M-16DX Lasse Kärkkäinen
2008-07-24 2:38 ` Jon Smirl
-- strict thread matches above, loose matches on Subject: below --
2015-10-23 8:27 Ricard Wanderlof
2015-10-23 11:01 ` Clemens Ladisch
2015-10-23 14:44 ` Ricard Wanderlof
2015-10-23 15:08 ` Clemens Ladisch
2015-10-24 5:51 ` Ricard Wanderlof
2015-11-12 7:58 ` Ricard Wanderlof
2015-11-12 12:38 ` Clemens Ladisch
2008-07-17 9:29 Lasse Kärkkäinen
2008-07-24 8:17 ` Clemens Ladisch
2008-11-10 3:53 ` Lasse Kärkkäinen
[not found] ` <491C6E10.7090308@trn.iki.fi>
[not found] ` <1226624101.4836.95.camel@localhost>
2008-11-14 8:12 ` Clemens Ladisch
2009-03-15 2:06 ` Lasse Kärkkäinen
2009-03-16 7:04 ` Takashi Iwai
2009-05-27 20:49 ` Lasse Kärkkäinen
2009-05-27 21:08 ` Takashi Iwai
2009-05-28 11:03 ` Lasse Kärkkäinen
2009-05-29 6:35 ` Takashi Iwai
2009-05-29 10:53 ` Lasse Kärkkäinen
2009-06-01 9:11 ` Takashi Iwai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.