[alsa-devel] arecord: buffer-size dependency on period-size and other params

[Jaroslav Kysela]

Dne 15. 01. 20 v 14:47 Rajwa, Marcin napsal(a):
> Hello,
> 
> I have spotted strange behavior of alsa-lib when I try to set
> buffer-size in arecord. It looks like the size of the buffer is very
> dependent on other parameters like period-size and rate for example. At
> first it sounds like normal behaviour, after all buffer size smaller
> than period size doesn’t make much sense. However what if we go in the
> reverse direction and set buffer-size much larger than period size? Then
> I see no reason to forbid such request (at least on the user space
> level). So to be specific I issue such command: arecod -Dplughw:0,8 -r
> 16000 -c 2 -f S24_LE --buffer_size 1280000 tmp.wav -vvv. The arecord
> response for this is buffer size of 31992 frames, 255936 bytes. Now let
> me also tell the buffer size of 1280000 bytes is the maximum buffer size
> our driver allows, likewise max period is 268800 bytes. Now if inside
> our driver I double max period size limit I get buffer size accordingly
> bigger. Similarly, if I change the format in the command line request
> from S24_LE to i.e S16_LE then again I will get buffer size closer to my
> request (bigger). So below are my questions:
> 
>   1. Why alsa-lib behaves in a way I described above? Why I can not
>      control buffer size independently from other parameters (providing
>      it has physical sense).
>   2. It looks like alsa-lib first calculates initial buffer-size base on
>      other input params like mentioned period size or sampling rate and
>      then ask driver to refine it according to its capabilities. Is that
>      the case?

Yes. It appears like an issue in the refine mechanism.

>   3. I also tried to dump hw capabilities by adding –dump-hw-param flag
>      to my command line request and here yet another surprise – in a row
>      dedicated for buffer size it says “BUFFER_SIZE [12 4294967294]”.
>      Where is this “4294967294” comes from, and on what basics is it
>      calculated? I would expect at the bare minimum it should ask driver
>      but in the snd_pcm_hw_param_dump() function I don’t see any
>      communication with the driver.

This value may be -2 (or -ENOENT) - no idea. It may also be an overflow somewhere.

I would start to use only the direct 'hw:X' device for tests. If it works, the 
problem is with the plug plugin (automatic format conversion inside alsa-lib). 
There are several debug defines in src/pcm/pcm_params.c . You may use 
LD_PRELOAD to debug this problem.

						Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.