On Mon, 03 Aug 2009 16:00:32 +0200 Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
Hi, I made more testing on my OMAP1510 and found out that I could get your example usage working without my patch, but only if started like this:
arecord -D hw:0,0 -f S16_LE|aplay -D hw:0,0
If I start the same with "-D hw:0,0" omitted from aplay, it doesn't work any longer, waiting forever. It definitelly doesn't work if I start capture and playback one after another, no matter which one goes first (record while playing or play while recording). So it looks like starting both streams simultaneously can do the job, but a short delay breaks it.
With my patch, it seems to work fine for me in all cases.
So it looks that McBSP-DMA for another stream cease to work if there is more than certain delay between first stream start and second one but omap_mcbsp_pollwrite or _pollread will clear the error condition. Can you debug is this due clearing the possible XSYNC_ERR, waiting for transmit/receive confirmation or playing with data registers there?
Jarkko, have you ever tried it on your OMAP2/3 with parallel playback and capture started one after another, not simultaneously?
Yes I have. Like recording into file (arecord /dev/shm/foo) and start playing it after some time (aplay /dev/shm/foo) or playing a file and start recording into another.
If the problem appears to be OMAP1510 or AMS_DELTA specific, I can add a check for a machine or cpu type to avoid braking unaffected machines.
I'm thinking can your platform show some existing problem not noted before... but yes, check for 1510 would be bit safer now and is also kind of revisit comment why 1510 needs special handling.