I forgot to ask: what mode you are using the McBSP? Is it in element, or threshold mode? You can check/change the McBSP mode in: /sys/devices/platform/omap-mcbsp.2/dma_op_mode
It is in threshold mode, with max threshold 1023. I will try other modes.
This sounds safe, give the fact that the McBSP2 FIFO is 1280 word
long.
The McBSP FIFO configuration has been corrected in newer kernels.
One thing that I would try is to synchronize the McBSP2 FIFO configuration with the period size you use: 48KHz/stereo/16bit 10ms = 480 samples, so configure the McBSP2 FIFO to 960 (for both tx, and rx threshold). Might not help, but it worth a try...
We tried element and frame mode, playback doesn't sound correct with these mode, but the capture is OK. We will stick with threshold mode, and try the new threshold.
For playing, the left and right are the same data, we could not
tell if
the channel switch happens to playback as well.
I see. Is there a way for you to run your application to capture
only,
and from a separate app (aplay?) play a sample, which has audio
only
on
one channel?
I can fill zero to one of the play channel in our app to test it.
Great. Let's see, if the swap also happens in the playback path as well.
None of our test shows the playback problem. I think the playback path is fine, but will keep testing.
Also, we have verified the audio data from I2S interface looks fine using a scope even when the channels are switched. We can eliminate twl4030 codec from the problem, and focus on McBSP and DMA. We don't have chance to check McBSP overflow/underflow as you suggested yet.
Thanks, Ying