[alsa-devel] [PATCH 2/3] ASoC: DaVinci: pcm, rename variables in prep for ping/pong
Steve Chen
schen at mvista.com
Wed Sep 30 01:24:54 CEST 2009
On Tue, 2009-09-29 at 15:31 -0700, Troy Kisky wrote:
> Steve Chen wrote:
> > On Tue, 2009-09-29 at 15:09 -0700, Troy Kisky wrote:
> >>> Troy, do you have any theory yet on why your patch should permanently swap
> >>> channels?
> >>>
> >> Memory in 16 bit samples
> >> L1,R1,L2,R2
> >>
> >> Shifting out in 16 bit samples
> >> L1,R1,L2,R2
> >>
> >>
> >> Memory in 32 bit samples
> >> R1L1,R2L2,R3L3
> >>
> >> Shifting out in 32 bit samples
> >> R1L1,R2L2
> >>
> >> Codec sees 16 bit samples
> >> R1,L1,R2,L2
> >>
> >
> > If that is the case, wouldn't we see the channel swap on DM644x as well?
> >>From Sekhar's earlier e-mail, the channel swap appears specific to DM355
> > EVM.
> >
> > Steve
> >
> >
> Yes, unless an underrun causes the 1st 16 bit sample to be delayed when transmitting
> out 16 bit samples at a time. That is why the 16 bit shift leads to random swaps
> and 32 bit shifts leads to always swapped. When an underrun happens with 32 bit shifts
> the last sample (both left AND right) is merely shifted again. When an underrun happens
> with 16 bit shifts only the immediately preceding left OR right channel sample is repeated
> leading to a random swap.
>
I see, so "random" channel swap only happens for 16 bit shift and only
after an underrun. So if underrun does not happen, we should not see
any channel swap right?
As for the 32 bit shift, if the channels are always swapped, can we not
configure the DMA engine to automatically swap the upper and lower 16
bits to get around the issue? Am I missing something?
Steve
More information about the Alsa-devel
mailing list