arecord: buffer-size dependency on period-size and other params

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
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.

Kind Regards,

Marcin Rajwa

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux