All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lasse Kärkkäinen" <tronic+8nhy@trn.iki.fi>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: Roland/Edirol M-16DX
Date: Thu, 28 May 2009 14:03:39 +0300	[thread overview]
Message-ID: <4A1E6F8B.3000308@trn.iki.fi> (raw)
In-Reply-To: <s5hr5ya1cg3.wl%tiwai@suse.de>

[-- 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

  reply	other threads:[~2009-05-28 11:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17  9:29 Roland/Edirol M-16DX 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 [this message]
2009-05-29  6:35             ` Takashi Iwai
2009-05-29 10:53               ` Lasse Kärkkäinen
2009-06-01  9:11                 ` Takashi Iwai
2008-07-24  2:17 Lasse Kärkkäinen
2008-07-24  2:38 ` Jon Smirl
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A1E6F8B.3000308@trn.iki.fi \
    --to=tronic+8nhy@trn.iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.