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