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

[Mark Hills]

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