On Sun, 13 Feb 2011 09:48:00 +0000 peter.ujfalusi@nokia.com wrote:

...

...

We are using a customized TI OMAP3 with TWL4030, similar to OMAP3EVM board. We noticed occasionally (after bring up few hours) the mic channel audio is swapped. Has anyone seen similar problem? Any suggestion where the problem might be?

Is this with recent kernels? There were this channel swapping problem before but it got fixed by Eero Nurkkala for the 2.6.32 kernel by following commits:

This is something different. The channel swapping/shifting issue was affecting the playback stream only.

Hmm.. could be. Also IRCC before the swapping was quite frequent. Especially during the stream startup time but I think also sometimes while playback was running? This is infrequent but happens anyway.

I have not experienced with channel swapping during capture.. It would help, if I know: what is your kernel version Source of the recording (digimic, HS, main mic, etc)

We are using 2.6.32. The source of the recording is using Analog Mic. The Left Main mic is always on, and Right Sub mic can be either on or off when this occurs. We are not using AUX or digimic.

To clarify: you experience sudden channel switch during active recording, when the recording was running for few hours? Or is it that you start/stop the recording, and sometimes the channels are swapped?

It is sudden channel switch during active recording. There is no XRUN or any noticeable error when this happens.

This is a VoIP app, we have duplex audio when this happens. Both capture and playback are setup to run at 48kHz, 2 channel, S16_LE, with period size 10 mSec.

For playing, the left and right are the same data, we could not tell if the channel switch happens to playback as well.

Thanks, Ying

Hi,

On 02/15/11 01:33, ext ylin@mail.com wrote:

Some update: We peeked into the substream->dma_buffer.area, and found out the channels are already switched in DMA buffer. We are looking into McBSP2 and DMA to find some clues, but not familiar in these areas. Any suggestion how to further narrow down the problem?

Few more things: I suppose the twl4030 is the master on the bus (McBSP slave) Since you are using stereo capture, I assume the digital interface is in I2S mode.

I could think of three source for channel switch: 1. The switch happens within the twl4030 codec itself 2. Switch happens because of underflow situation in McBSP 3. Switch happens because of overflow situation in McBSP

To narrow down the problem: 1. You need tracepoints on you board for McBSP2 pins, and a scope You need to monitor the DX, and FS lines (bitclock might be useful as well). Keep the right channel disabled, and run your application, observe the DX/FS on the scope. When you notice the channel swap, check back on the scope, if the data moved from left to right channel.

2/3. This is a bit more trickier, but I have done this several times: You need to use the PRCM compliant interrupt configuration. Do not request the TX/RX (62, 63 for McBSP2) interrupts in omap_mcbsp_request, but request only the common IRQ (17 for McBSP2). Enable the ROVFLEN, RUNDFEN, and RSYNCERREN bits in IRQENABLE_REG. In the ir handler check for these enabled events (in IRQSTATUS_REG), and print out the reason for the event (Do not forget to write back the register content to IRQSTATUS_REG to ack the event).

I hope this helps narrowing down the problem.

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.

...

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.

Thanks, Ying

...

...

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

...

We tried element and frame mode, playback doesn't sound correct

with

...

these mode, but the capture is OK.

Hrm, this does not sound right... Historically the element mode was

the

first and only mode of using McBSP. The threshold mode has been added

later.

Could you explain what do you mean, when you said that the playback

was

not correct? I have never experienced problems with the element mode.

The element mode works fine with playback after I fill more data to the buffer. We try to optimize the delay and keep the minimum data in the buffer. However, the element mode timing is slightly different from threshold, and we have under-run condition. With filling extra data to the buffer, the element mode works fine. We are testing if we see the channel switch with this mode.

In what mode you are using the TWL4030 codec? Is it master? If it is master, can you compare your machine driver with for example the Beagle board's machine driver?

It is in master mode. We are using OMAP3EVM board as reference. Our kernel is based on the TI P3P release. # /proc/ti-psp-version AM37x/DM37x Linux PSP version 03.00.01.06 (OMAP3PHX) We are using the same audio drivers for OMAP3EVM. There is only some unrelated patches to the driver, such as ramp delay and Bluetooth PCM support.

Or can you share the relevant configuration (from your machine driver) with us?

I am not sure exactly the relevant configuration to share. Here is the TWL4030 codec registers with both Tx and Rx audio running. Please let me know if you like to see other configurations and I can pull them out. # cat /sys/devices/platform/soc-audio/codec_reg twl4030 registers 0: 0 1: a3 2: c3 3: 0 4: 7 5: 31 6: 0 7: 8 8: 0 9: 0 a: 9 b: 9 c: 9 d: 9 e: 1 f: 0 10: 0 11: 0 12: 3f 13: 3f 14: 0 15: 0 16: 0 17: c 18: 0 19: 0 1a: 0 1b: 2b 1c: 2b 1d: 0 1e: 0 1f: 0 20: 0 21: 10 22: 0 23: 5 24: 4 25: 0 26: 0 27: 0 28: 0 29: 0 2a: 3f 2b: 0 2c: 0 2d: 0 2e: 0 2f: 0 30: 0 31: 0 32: 0 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 3a: 16 3b: 0 3c: 0 3d: 0 3e: 2 3f: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 22 49: 0 4a: 2 #

...

and focus on McBSP and DMA. We don't have chance to check McBSP overflow/underflow as you suggested yet.

If we don't figure out what is the problem, you might need to do

this...

I am working on this.

Thanks, Ying

Hi,

On 02/20/11 06:01, ext ylin@mail.com wrote:

...

...

Or can you share the relevant configuration (from your machine

driver)

...

...

with us?

And, these are McBSP2 registers with both Tx and Rx audio running. **** McBSP2 regs **** DRR2: 0xffee DRR1: 0x0000 DXR2: 0x0000 DXR1: 0x0000 SPCR2: 0x02f5 SPCR1: 0x0031 RCR2: 0x8041 RCR1: 0x0040 XCR2: 0x8041 XCR1: 0x0040 SRGR2: 0x001f SRGR1: 0x0f00 PCR0: 0x000f

---

Both the twl and McBSP config seams to be in sync. I do not see anything, which stands out...

I think you need to implement the PRCM compliant interrupt config to check for McBSP underflow/overflow.

I'll try to resurrect my Beagle board, since that as well have the twl codec on McBSP2...

...

I think you need to implement the PRCM compliant interrupt config to check for McBSP underflow/overflow.

I have implemented the interrupt handle for IRQ 17 for receive error and underflow/overflow. However, the devices are running for 2 days without channel swapped. I will keep them running.

Finally, after 4 days, we caught the problem again. When channel is swapped, the IRQ is trigger with receive underrun (IRQ_STATUS_REG = 0x171e). And, from the status register, the transmit is overflow as well. However, I didn't fill zero to one of the transmit channel, and couldn't tell if the playback is swap as well. Any idea why underun happens, or any suggestion to fix it?

Thanks, Ying

...

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...

I checked the threshold registers, both are 960 (959 to be precious). It is a safe value, but the channel is switched with 960. In addition, we have tested with sample rate at 16kHz and still have the problem.

Thanks, Ying

...

We are using 2.6.32. The source of the recording is using Analog

Mic.

...

The Left Main mic is always on, and Right Sub mic can be either on

or

...

off when this occurs. We are not using AUX or digimic.

I was thinking is this 2.6.32 derived completely from Vanilla version

or

only partially? I think I've seen some case where the kernel was

forked

earlier and got upgraded to the upstream version only partially.

Even Peter told that those channel switching patches in 2.6.32 should fix the playback case only, worth to check just in case are those

fixes

in your kernel tree.

Those fixes are not in our kernel, I will apply them and re-test.

Thanks, Ying

On Wed, 16 Feb 2011 22:53:25 -0500 ylin@mail.com wrote:

...

...

Even Peter told that those channel switching patches in 2.6.32

should

...

...

fix the playback case only, worth to check just in case are those

fixes

...

in your kernel tree.

Those fixes are not in our kernel, I will apply them and re-test.

We applied those 2 patches, but still have channel swapping issue from capture audio.

Thanks, this is very good information and seems to indicate the same problem must be in upstream also as I don't recall that there were any other swapping related fixes than those that fix the playback case.