From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: Swapped channels issue on pxa-ssp based platforms Date: Mon, 07 Nov 2011 21:19:07 +0100 Message-ID: <4EB83D3B.2050906@ladisch.de> References: <4EB817FC.4000905@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by alsa0.perex.cz (Postfix) with ESMTP id B8B2C2450D for ; Mon, 7 Nov 2011 21:19:20 +0100 (CET) In-Reply-To: <4EB817FC.4000905@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Daniel Mack Cc: alsa-devel@alsa-project.org, Mark Brown , Sven Neumann , Liam Girdwood , Haojian Zhuang List-Id: alsa-devel@alsa-project.org Daniel Mack wrote: > we're hunting a weird bug on PXA3xx/ssp based audio devices which causes > the playback channels to be swapped when the capture stream is started > at the same time. Content for the left channel appears on the right and > vice versa, in approximately 50% of all test runs IIRC there was some other CPU where it was tried to program a generic serial output to handle I=B2S data. The same symptoms appeared because it was not possible to synchronize the start of the L/R signal to the start of the DMA. Apparently, the starting of the capture stream affects the L/R synchronization of the playback stream. Does starting playback first work? > I guess this is some sort of a race condition in the stream startup, > and suspected sound/soc/pxa/pxa-ssp.c to lack some locking, so I added > a spinlock around all register read-modify-write cycles. But that doesn't > seem to be the reason. I'd guess this is a race in the programming of the L/R clock signals; try putting a lock/mutex about all the stream initialization code, and maybe adding some delay. Regards, Clemens