[alsa-devel] Channel swapping issue on TI OMAP3/TWL4030

[ylin at mail.com]

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