[alsa-devel] Buffer size/periods (Layla3G)

[Giuliano Pochini]

On Sun, 16 Mar 2008 12:02:58 +0000 (GMT)
Mark Hills <mark at pogo.org.uk> wrote:

> Hello,
>
> I am investigating problems I'm having with recording over long periods.
> I'm using a Layla3G and tested various ALSA versions including 1.0.14 and
> 1.0.16 on different machines.
>
> I've noticed that when I open the first pair of subdevices, my request for
> 1000ms buffer size is handled differently to other devices:
>
>    $ ./test_buffers "hw:Layla3G,0,0" 1000
>    buffer_size=16384 period_size=128
>
>    $ ./test_buffers "hw:Layla3G,0,2" 1000
>    buffer_size=32768 period_size=256

This is caused by the preallocation policy I applied. Since those cards
have a lot of channels I though it is a waste of non-swappable
kernel memory to preallocate memory for each one. So the driver preallocates
128KiB for the first two channels of each device only, which are by far the
most used ones (see echoaudio.c::snd_echo_preallocate_pages()). ALSA does
not allow apps to use buffers bigger than the preallocated memory. In your
test: buffer_size=16384*2 channels*4 bytes/channel = 128KiB.

For channels >=2 the memory hasn't been preallocated, thus it is allocated
upon request. Its limit is 256KiB (see echo3g.c), so your test program gets
proportionally longer buffers.

You can set the amount of preallocated memory from userspace by writing
into the files listed by:

find /proc/asound/ -name prealloc\*


> If I try other buffer sizes, I can see is a limit to buffer size of 16384
> samples on the ,0 subdevice, which is also affecting the chosen period
> size. But only on the first subdevice. Is there a reason, or is this a
> bug?

All periods must have the same length and, on Echoaudio cards, it must be a
multiple of 32. ALSA computes the nearest buffer length to the requested
value and chooses the period length as it prefers because your program
doesn't set it.


> Also, there seem to be failures at certain buffer sizes:
>
>    $ ./test_buffers "hw:Layla3G,0,2" 429
>    buffer_size=18912 period_size=96
>
>    $ ./test_buffers "hw:Layla3G,0,2" 430
>    set_buffer_time_near: Invalid argument
>
>    $ ./test_buffers "hw:Layla3G,0,2" 431
>    buffer_size=19008 period_size=96

This shouldn't happen. I'll give it a look.


> The overall problem I'm investigating is snd_pcm_readi() returning
> incomplete buffers after running for long periods until another
> snd_pcm_prepare(). It seems possible that this is related.

I don't think so. Btw I never really tried to record for long periods. It
may depend on the fact that the DMA counter has a limit of 4GiB and then it
overflows, but the driver should handle it nicely. Do you know after how
many bytes of audio data it fails ?



--
Giuliano.