From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: ext Jason Fox <jfox@gai-tronics.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Channel swapping problem on Atmel SSC audio
Date: Fri, 18 Feb 2011 09:06:13 +0200 [thread overview]
Message-ID: <4D5E1A65.40500@nokia.com> (raw)
In-Reply-To: <1297950320.7194.57.camel@alice.bigman.com>
Hi,
On 02/17/11 15:45, ext Jason Fox wrote:
> 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 not familiar with the Atmel platform, but we have had similar
channel swap/shift problems (random channel swap at stream start) in
OMAP3 McBSP.
In our case it was due to the fact, that OMAP3 McBSP has two bits to
actually enable the digital interface.
The early code enabled this two bit at the same time, and that was the
root of the problem.
This is what happened:
- DMA has been configured, and started (HW synchronized DMA, McBSP
requests the DMA to push data)
- McBSP got enabled, and got released at the same time
McBSP immediately signaled the DMA to push data.
Depending on the timing, there were cases, when McBSP started to send
out the data, while the DMA has not pushed anything to McBSP FIFO.
So the first word was 0, and the second was the first word from the
sample -> channels swapped.
This has happened in McBSP slave configuration as well: depending on the
timing of the McBSP start we have seen random channel swap.
If the McBSP was enabled just right before the start condition on the
I2S bus, it sent out 0 for the first word, and than the audio data ->
channel swapped.
We have fixed this by first enabling the McBSP, but keeping it
unreleased state. When McBSP is enabled, it will trigger DMA to start
pushing data, so we have valid audio data in the FIFO.
We wait for 500us.
We release the McBSP. At this point it will either start listening for
the start condition on I2S bus (slave), or start the clocks on the bus.
Since we already had the valid audio data in the FIFO, the channel swap
has gone.
I suppose you also have similar issue.
Other solution which we considered could have been used only in case of
16bit/stereo audio:
Configure McBSP for 32bit word length (and single slot) in case of
16bit/streo audio. When the race happens McBSP would have sent 0 for
both channels, so we would not have the channels swapped. But this will
only work with 16bit/stereo mode - and mono as well ;)
So we sticked with the former solution.
I hope this helps for you to figure out something similar for your problem.
--
Péter
next prev parent reply other threads:[~2011-02-18 7:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 13:45 Channel swapping problem on Atmel SSC audio Jason Fox
2011-02-18 7:06 ` Peter Ujfalusi [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-11-10 22:49 Ryan Mallon
2010-11-11 12:27 ` Alan Horstmann
2010-11-12 8:06 ` Patrick Ziegler
2010-11-12 9:52 ` Irfan Shaikh
2010-11-14 20:37 ` Ryan Mallon
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=4D5E1A65.40500@nokia.com \
--to=peter.ujfalusi@nokia.com \
--cc=alsa-devel@alsa-project.org \
--cc=jfox@gai-tronics.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).