[alsa-devel] Swapped channels issue on pxa-ssp based platforms
Hi,
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 of the following command:
$ arecord -f cd - -D hw:0,0 | aplay -D hw:0,0 -f cd -
When just aplay is used, everything's fine.
It's unrelated to the codec part, as we see this with machines that feature different models. 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.
It could also be the DMA engine that writes to the wrong position, but I fail to see it right now.
Does anyone have an idea where to look for the culprit? Have there been similar effects in other SoC platforms?
Thanks for sharing your thoughts :)
Daniel
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²S 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
On Mon, Nov 07, 2011 at 09:19:07PM +0100, Clemens Ladisch wrote:
Daniel Mack wrote:
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.
That's very unlikely to help, these issues are generally issues with the controller not being able to figure out which clock edge to start on properly and if there are problems here locking is unlikely to help - the issue is the two hardware blocks synchronizing with each other, usually with the clocks driven from an asynchronous domain.
On 11/08/2011 12:39 PM, Mark Brown wrote:
On Mon, Nov 07, 2011 at 09:19:07PM +0100, Clemens Ladisch wrote:
Daniel Mack wrote:
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.
That's very unlikely to help, these issues are generally issues with the controller not being able to figure out which clock edge to start on properly and if there are problems here locking is unlikely to help - the issue is the two hardware blocks synchronizing with each other, usually with the clocks driven from an asynchronous domain.
Unfortunately, yes. We're currently trying to do some more investigation of the exact effects, see if we have swapped channels on both streams (which the "aplay | arecord" wouldn't unveil) etc.
Still, I wonder whether locking wouldn't be important in sound/soc/pxa/pxa-ssp.c, as all the per-substream functions actually operate on the registers of the ssp port that is shared between capture and playback. And the code does things like
u32 sscr0 = pxa_ssp_read_reg(ssp, SSCR0); if (cpu_is_pxa25x() && ssp->type == PXA25x_SSP) { sscr0 &= ~0x0000ff00; sscr0 |= ((div - 2)/2) << 8; /* 2..512 */ } else { sscr0 &= ~0x000fff00; sscr0 |= (div - 1) << 8; /* 1..4096 */ } pxa_ssp_write_reg(ssp, SSCR0, sscr0);
all over the place. I'm just curious whether there there is anything in the ASoC core that cares for this?
Thanks, Daniel
On 11/08/2011 01:27 PM, Mark Brown wrote:
On Tue, Nov 08, 2011 at 12:46:40PM +0100, Daniel Mack wrote:
all over the place. I'm just curious whether there there is anything in the ASoC core that cares for this?
There's a big fat mutex around each PCM.
That explains why it didn't hit us earlier. Thanks :)
On Tue, Nov 8, 2011 at 1:40 AM, Daniel Mack zonque@gmail.com wrote:
Hi,
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 of the following command:
$ arecord -f cd - -D hw:0,0 | aplay -D hw:0,0 -f cd -
When just aplay is used, everything's fine.
It's unrelated to the codec part, as we see this with machines that feature different models. 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.
It could also be the DMA engine that writes to the wrong position, but I fail to see it right now.
Does anyone have an idea where to look for the culprit? Have there been similar effects in other SoC platforms?
Thanks for sharing your thoughts :)
Daniel _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi Daniel,
I assumed that you're using pxa3xx or pxa93x silicons. Do you also enable D0CS operating point? If you disable this operating point, does this issue exist?
If the codec is configured as master mode, does this issue exist?
Thanks Haojian
participants (4)
-
Clemens Ladisch -
Daniel Mack -
Haojian Zhuang -
Mark Brown