On Thursday 23 April 2009 14:04:05 ext Alan Horstmann wrote:
On Thursday 23 April 2009 10:20, Peter Ujfalusi wrote:
On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
Problem 2: Test tone is being presented by the user application, providing a 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left channel is quiet. The data seems to slip back and forth from left to right channel. This is reproducable and verified with a scope trace.
Anybody have any ideas what might be going wrong here? Traces for codec reg dump and mcbsp are attached.
As Jarkko already asked: are you seeing the channel switch while running or is it happens on playback start?
AFAIK this phenomena can be also seen on Beagle board.
I have done some investigation regarding to these, but so far I can not say that I know what causes it.
BTW: these are separate issues (startup switch and runtime switch).
I just want to declare an interest in this investigation. Many months back I was working on a SAM9260 board with wm8731 codec; the project is rather 'background' at present. One of the outstanding unresolved (not really investigated much either) issues was of channel swapping at start of capture or playback. It never changed during operation, but each start time the channels would be randomly correct or swapped.
So in case of OMAP35XX, when the switch happens?
I have a theory, which needs to be checked for the startup switch in OMAP: I think what is happening, that the McBSP module got enabled earlier then the DMA is started. This leads to and underrun situation in McBSP (no data in the buffer), so McBSP will transmit _something_ when the start condition for the I2S is met. When the DMA starting to push data to McBSP, than valid data will be shifted out. McBSP is shifting word by word manner. So if the first word transmit need to be done, when the buffer is empty, it starts to shift the word, than the data arrives from the DMA, the next word will be valid data -> you will have a nice channel switch.
Is this makes sense?
Does this indicate that the implementation/drivers of i2s has a fundamental ambiguity? Is it not rigidly defined which channel should follow a rising edge of L/R clock?
Alan