[From nobody Thu May 28 13:04:26 2009
Return-Path: <james@jamestrev.com>
X-Original-To: tronic@trn.iki.fi
Delivered-To: tronic@trn.iki.fi
Received: from trn.iki.fi (localhost [127.0.0.1])
	by trn.iki.fi (Postfix) with ESMTP id A34BA45B7D28C
	for <tronic@trn.iki.fi>; Fri, 14 Nov 2008 01:55:13 +0200 (EET)
Received: from bigbox.jt.com (host-83-217-174-146.sta.dsl.vispa.com
	[83.217.174.146]) by trn.iki.fi (Postfix) with ESMTP
	for <tronic+cv5n@trn.iki.fi>; Fri, 14 Nov 2008 01:55:12 +0200 (EET)
Received: from [192.168.10.13] (babybox.jt.com [::ffff:192.168.10.13])
	by bigbox.jt.com with esmtp; Fri, 14 Nov 2008 00:07:29 +0000
	id 0084C005.491CC141.00005F44
Subject: Re: [alsa-devel] Roland/Edirol M-16DX
From: James Trevelyan <james@jamestrev.com>
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
In-Reply-To: <491C6E10.7090308@trn.iki.fi>
References: <487F10EE.6030405@trn.iki.fi> <48883AAC.6060101@ladisch.de>
	<4917B029.7010809@trn.iki.fi>  <491C6E10.7090308@trn.iki.fi>
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 14 Nov 2008 00:55:01 +0000
Message-Id: <1226624101.4836.95.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.0 
Content-Transfer-Encoding: 8bit
X-LimZero: valid lzID=cv5n

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

]