[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100511173830.GF30801@buzzloop.caiaq.de>
Date: Tue, 11 May 2010 19:38:30 +0200
From: Daniel Mack <daniel@...aq.de>
To: Pedro Ribeiro <pedrib@...il.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
gregkh@...e.de, konrad.wilk@...cle.com, tiwai@...e.de,
USB list <linux-usb@...r.kernel.org>, clemens@...isch.de,
Kernel development list <linux-kernel@...r.kernel.org>,
chrisw@...s-sol.org, iommu@...ts.linux-foundation.org,
andi@...stfloor.org, Andrew Morton <akpm@...ux-foundation.org>,
dwmw2@...radead.org
Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
On Tue, May 11, 2010 at 06:32:50PM +0100, Pedro Ribeiro wrote:
> On 11 May 2010 18:10, Daniel Mack <daniel@...aq.de> wrote:
> > No surprise here. The 4 channels are mux'ed in an interleaved fashion,
> > so if the buffers contain rubbish, you will hear artefacts on all
> > channels.
>
> So what would be the testcase you would like me to try?
Would be good to see what happens if you could record audio (with
arecord would be sufficient), just to see whether the same problem
exists in the other direction.
Either record an externally generated sine tone and open the resulting
wave file in an editor. With the amount of artefacts you describe, they
should easily be visible.
Another option is to play back any kind of recorded audio thru an audio
device that does not show the problem (some internal, onboard device?).
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists