[alsa-devel] ALSA dma ring buffer issue on 2.6.14

[Filipe Braz]

Hi,

I am trying to use ALSA with the OMAP2430 embedded platform, using
kernel 2.6.14 for low latency voip applications.

The problem seems to be that the driver ring buffer is not filled by
the alsa kernel/core on time to be sent to the hw codec.

So, If I use the following large buffer size / period-size it works fine:

aplay --period-size=1024 --buffer-size=8192 -f S16_LE -c 2 -r 8000 pattern.pcm

But if I use smaller buffer / period sizes such as the following it
does not work:

aplay --period-size=32 --buffer-size=128 -f S16_LE -c 2 -r 8000 pattern.pcm

aplay --period-size=32 --buffer-size=256 -f S16_LE -c 2 -r 8000 pattern.pcm

aplay --period-size=64 --buffer-size=512 -f S16_LE -c 2 -r 8000 pattern.pcm

aplay --period-size=128 --buffer-size=512 -f S16_LE -c 2 -r 8000 pattern.pcm

aplay --period-size=256 --buffer-size=1024 -f S16_LE -c 2 -r 8000 pattern.pcm

aplay --period-size=512 --buffer-size=2048 -f S16_LE -c 2 -r 8000 pattern.pcm

I am playing a special pattern sound file that I verify before each
period is transfered to the codec via dma (on the driver).
On smaller buffer sizes. the 1st period AFTER the ringbuffer rotates
to the beginning, appears to not contain the pattern data (instead is
filled with zeros). This does not happens with larger buffer /
periods.
On all cases the pattern file is large enough so that the dma ring
buffer rotates several times until transfer is complete.

I have tested this on the pc and it works just fine.
Also if I use the OSS driver for the OMAP2430 instead of the ALSA it
works fine. ALSA with OSS emulation works significantly better but
there is still some distortion.

Any ideas why this happens? Is this a known issue or is there a
solution for this problem?

Thanks in advance,
Filipe