Hi,

Note: I opened a thread on TI's E2E forums too, the thread is at: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/185810.asp... Linux is v3.3.

Repeating what I have put there:

- As we will be using multiple codecs on McASP, we have put the codecs as slaves. We are also using a 8.192MHz external master clock. - We have patched davinci-mcasp.c to handle this mode ("SND_SOC_DAIFMT_EM_CBS_CFS"), and refer to it for the CPU DAI configuration in the machine driver. - Our setup currently has an AIC3X codec, connected to the TX clocks of McASP. The RX clocks are not used, they are left hanging, so we need to enable the TX clocks even when recording. - We only plan to support 32kHz, so currently we have left an ugly hack in the code. - It almost works, but we have a nasty problem:

- When performing a capture alone, the sound is recorded as expected - When performing a playback alone, no problem - When starting a playback then a capture, no problem - When starting a capture then a playback, the playback will hang, the stream won't accept more data; no perturbation on the recording side.

A review of the McASP code WRT/ SPRUH77A (OMAP-L138 Technical Reference Manual) does not really help.

Now, I performed some tracing:

- patched the davinci-mcasp.c code, to trace register accesses See attached file. The patch also contains the differences explained on the e2e forum post. - produced the "yes" file by running the "playback then capture" scenario: dmesg -c cat /dev/urandom | pv -B 3200 | aplay -f S16 -r 32000 aplay -B 20000 -f S16 -r 32000 -C -V mono /dev/null dmesg -c | gzip > yes.gz - produced the "no" file by running the "capture then playback" scenario: dmesg -c aplay -B 20000 -f S16 -r 32000 -C -V mono /dev/null cat /dev/urandom | pv -B 3200 | aplay -f S16 -r 32000 dmesg -c | gzip > no.gz

And I still have issues seing what could be wrong.

Could you somehow help me ?

Best regards,