[alsa-devel] Channel swapping problem on Atmel SSC audio

Ryan Mallon ryan at bluewatersys.com
Sun Nov 14 21:37:24 CET 2010


On 11/12/2010 10:52 PM, Irfan Shaikh wrote:
> I had faced the similar issue on IMx31. The cause there was reversal of LRCK clock {180 degree phase shift}.
> probing the LRCK clock may help you to find the problem
> 
> ________________________________________
> From: alsa-devel-bounces at alsa-project.org [alsa-devel-bounces at alsa-project.org] On Behalf Of Patrick Ziegler [patrick.ziegler at fh-kl.de]
> Sent: Friday, November 12, 2010 1:36 PM
> To: alsa-devel at alsa-project.org
> Cc: Ryan Mallon
> Subject: Re: [alsa-devel] Channel swapping problem on Atmel SSC audio
> 
> Am 11.11.2010 13:27, schrieb Alan Horstmann:
>> On Wednesday 10 November 2010 22:49, Ryan Mallon wrote:
>>
>>> I'm working on a custom board using the AT91SAM9G45 processor and a
>>> TLV320AIC26 SPI attached audio codec using I2S format audio. When doing
>>> audio playback on the board the left and right channels are occasionally
>>> flipped.
>>>
>> <snip>
>>
>>
>>> Has anybody else had this problem, or does anybody have any AT91/Atmel
>>> hardware that they could test to see if it occurs on other hardware also?
>>>
>> I have worked with the AT91SAM9260 on a project which is currently suspended
>> (other priorities), where we had a simiar problem, with a codec on SPI.
>> Every time audio was started (capture or playback) the channels could be
>> swapped.  Solving that issue remains TODO when we restart.
>>
>> There was a thread on alsa-devel last month 'Soc Atmel SSC stereo problem'
>> with some suggestions.

Okay, so it's not just me.

>>
> In the thread mentioned, Alan proposed me amongst other things to test
> the LRCK level before starting the SSC. This works well for me. Maybe it
> should be implemented in a more generic way but the following
> modification does the trick for me.
> 
> in function  atmel_pcm_trigger inside file sound/soc/atmel/atmel-pcm.c :
> 
> case SNDRV_PCM_TRIGGER_START:
> +while(!at91_get_gpio_value(AT91_PIN_PB12));
> +while(at91_get_gpio_value(AT91_PIN_PB12));
> 
> case SNDRV_PCM_TRIGGER_RESUME:
> +while(!at91_get_gpio_value(AT91_PIN_PB12));
> +while(at91_get_gpio_value(AT91_PIN_PB12));

This appears to work, or at least makes the problem much more rare. I'm
trying to understand if the problem is a silicon bug in the AT91
hardware, or if the DMA start code in the Atmel SoC driver is buggy.

I'm running with the CPU as the master (generating LRCLK and BCLK) and
testing with playback (so CPU is clocking the data out). The TCMR
register has the CKS field set to 0x4 (start on falling edge of LRCLK),
so the above loops should not be necessary. I suspect that the above fix
only makes the problem occur much less frequently, rather than fixing it
correctly?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934


More information about the Alsa-devel mailing list