[alsa-devel] Buffer size/periods (Layla3G)
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
$ ./test_buffers "hw:Layla3G,0,4" 1000 buffer_size=32768 period_size=256
$ ./test_buffers "hw:Layla3G,0,6" 1000 buffer_size=32768 period_size=256
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?
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
Can anyone explain to me what's going on here, or is this also a bug?
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.
Any help is greatly appreciated.
Thanks,
Mark
On Sun, 16 Mar 2008 12:02:58 +0000 (GMT) Mark Hills mark@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.
Hi Guiliano,
Thanks for the quick reply.
On Sun, 16 Mar 2008, Giuliano Pochini wrote:
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.
Thanks for the explanation. I'm glad that there is good reason and that it's not a bug.
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.
When I do set it in my program, it is using the requested size in all cases. So I've found the period size to be working fine.
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.
Thanks! I can do any testing you might need -- at the moment I have access to two Layla cards in different machines. I've had similar problems previously with allocating a buffer of 256 frames, but these problems mysteriously disappeared before I was able to produce a meaningful bug report, so perhaps they are intermittent.
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 ?
I don't, but I've noticed the problems take days to show themselves which is a lot larger than 4Gb. I'll do some more detailed investigation and let you know.
Thanks for the help, it's greatly appreciated.
Mark
On Sun, 16 Mar 2008 22:12:39 +0000 Giuliano Pochini pochini@shiny.it wrote:
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.
Still no luck on this issue. ioctl() called from pmc_hw.c::hw_refine_call() fails. I'll look at the kernel part tomorrow.
-- Giuliano.
On Sun, 16 Mar 2008 22:12:39 +0000 Giuliano Pochini pochini@shiny.it wrote:
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.
It seems that ALSA can't manage to find a working hwparams combo. The card has the following constraints:
buffer size: 64-32768 frames period size: multiple of 32 frames periods: 2-220
It happens that ALSA restricts the allowable buffer size range to 18976-18976 which is very close to the requested 430ms. This is bad because the biggest multiple of 32 divisor of 18976 is 32. 18976/32 = 593 > maximum number of periods. return -EINVAL.
BUFFER_TIME = (430294 430295) -> (430294 430295) Rule 8 [e20b3944]: RATE = [44100 44100] -> [44100 44100] Rule 15 [e20b38d0]: BUFFER_SIZE = [18976 32768] -> [18976 18976] Rule 17 [e20b38d0]: BUFFER_BYTES = [151808 262144] -> [151808 151808] Rule 19 [e20b3944]: BUFFER_TIME = (430294 430295) -> (430294 430295)
Note that if you change the order of the hw_params_*() calls the problem goes away. It might show up again for some other values though.
I don't know how to fix it. Any clue ??
-- Giuliano.
participants (2)
-
Giuliano Pochini -
Mark Hills