Swapped channels issue on pxa-ssp based platforms

Swapped channels issue on pxa-ssp based platforms

[Daniel Mack]

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

Re: Swapped channels issue on pxa-ssp based platforms

[Clemens Ladisch]

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

Re: Swapped channels issue on pxa-ssp based platforms

[Mark Brown]

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.

Re: Swapped channels issue on pxa-ssp based platforms

[Daniel Mack]

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

Re: Swapped channels issue on pxa-ssp based platforms

[Mark Brown]

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.

Re: Swapped channels issue on pxa-ssp based platforms

[Daniel Mack]

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 :)

Re: Swapped channels issue on pxa-ssp based platforms

[Haojian Zhuang]

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