[alsa-devel] ALSA dma ring buffer issue on 2.6.14
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
participants (1)
-
Filipe Braz