* [alsa-devel] arecord: buffer-size dependency on period-size and other params
@ 2020-01-15 13:47 Rajwa, Marcin
2020-01-15 14:14 ` Jaroslav Kysela
2020-01-15 14:52 ` Ricard Wanderlof
0 siblings, 2 replies; 3+ messages in thread
From: Rajwa, Marcin @ 2020-01-15 13:47 UTC (permalink / raw)
To: alsa-devel
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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [alsa-devel] arecord: buffer-size dependency on period-size and other params
2020-01-15 13:47 [alsa-devel] arecord: buffer-size dependency on period-size and other params Rajwa, Marcin
@ 2020-01-15 14:14 ` Jaroslav Kysela
2020-01-15 14:52 ` Ricard Wanderlof
1 sibling, 0 replies; 3+ messages in thread
From: Jaroslav Kysela @ 2020-01-15 14:14 UTC (permalink / raw)
To: Rajwa, Marcin; +Cc: alsa-devel
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@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [alsa-devel] arecord: buffer-size dependency on period-size and other params
2020-01-15 13:47 [alsa-devel] arecord: buffer-size dependency on period-size and other params Rajwa, Marcin
2020-01-15 14:14 ` Jaroslav Kysela
@ 2020-01-15 14:52 ` Ricard Wanderlof
1 sibling, 0 replies; 3+ messages in thread
From: Ricard Wanderlof @ 2020-01-15 14:52 UTC (permalink / raw)
To: Rajwa, Marcin; +Cc: alsa-devel
On Wed, 15 Jan 2020, Rajwa, Marcin wrote:
> 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
Not an answer to your problem, but just a note: according to arecord -h,
the --buffer_size parameter is in frames (in your case, with S24_LE and 2
channels, the frame size is 4*2 = 8 bytes), not bytes.
/Ricard
--
Ricard Wolf Wanderlof ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-01-15 14:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-15 13:47 [alsa-devel] arecord: buffer-size dependency on period-size and other params Rajwa, Marcin
2020-01-15 14:14 ` Jaroslav Kysela
2020-01-15 14:52 ` Ricard Wanderlof
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).