[alsa-devel] snd_pcm_hw_params_set_buffer_time_near: invalid argument
Hi there.
I'm a bit puzzled as to what values are considered valids and which one aren't when it comes to setting the buffer time with snd_pcm_hw_params_set_buffer_time_near.
For example setting a value of 295ms : all ok. From 300ms to 450ms -> "Invalid argument". but 500ms for example is okay.
What's the logic behind it ? It's obviously related to the sampling rate, the audio format and the number of channels ; as the values giving me "Invalid argument" change then.
Any comments would be greatly appreciated.
Thanks! JY
2011/3/6 Jean-Yves Avenard jyavenard@gmail.com
Hi there.
I'm a bit puzzled as to what values are considered valids and which one aren't when it comes to setting the buffer time with snd_pcm_hw_params_set_buffer_time_near.
For example setting a value of 295ms : all ok. From 300ms to 450ms -> "Invalid argument". but 500ms for example is okay.
What's the logic behind it ?
Different sound card driver have different hardware constraints
e.g. HDA-Intel has the following constraints
snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 128); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128);
Attach a program buffertime.c to find out those buffer time with invalid argument ?
2011/3/6 Jean-Yves Avenard jyavenard@gmail.com
Hi there.
I'm a bit puzzled as to what values are considered valids and which one aren't when it comes to setting the buffer time with snd_pcm_hw_params_set_buffer_time_near.
For example setting a value of 295ms : all ok. From 300ms to 450ms -> "Invalid argument". but 500ms for example is okay.
What's the logic behind it ? It's obviously related to the sampling rate, the audio format and the number of channels ; as the values giving me "Invalid argument" change then.
Any comments would be greatly appreciated.
Thanks! JY
This seem to be bug in alsa-lib as I can reproduce using alsa-lib/test/pcm.c with buffer time 120000 and my hda codec support both 11025Hz and 22050Hz
using buffer time 160000 is OK
./pcm -Dhw:CARD=Intel,DEV=0 -b 120000 -r 22050 -c 2 Playback device is hw:CARD=Intel,DEV=0 Stream parameters are 22050Hz, S16_LE, 2 channels Sine wave rate is 440.0000Hz Using transfer method: write Unable to set buffer time 120000 for playback: Invalid argument Setting of hwparams failed: Invalid argument
./pcm -Dhw:CARD=Intel,DEV=0 -b 120000 -r 11025 -c 2 Playback device is hw:CARD=Intel,DEV=0 Stream parameters are 11025Hz, S16_LE, 2 channels Sine wave rate is 440.0000Hz Using transfer method: write Unable to set buffer time 120000 for playback: Invalid argument Setting of hwparams failed: Invalid argument
./pcm -Dhw:CARD=Intel,DEV=0 -b 160000 -r 11025 -c 2 Playback device is hw:CARD=Intel,DEV=0 Stream parameters are 11025Hz, S16_LE, 2 channels Sine wave rate is 440.0000Hz Using transfer method: write
On 7 March 2011 23:24, Raymond Yau superquad.vortex2@gmail.com wrote:
This seem to be bug in alsa-lib as I can reproduce using alsa-lib/test/pcm.c with buffer time 120000 and my hda codec support both 11025Hz and 22050Hz
using buffer time 160000 is OK
Yes.. It's hard to understand why 120ms wouldn't be okay, but 160ms would.
Could you check is 400ms works for you ? I found this to be a value that generally do not work when using 44.1kHz 6 channels audio.
For the time being, I made my application use 500ms buffer; this is what many media players are using (including mplayer) , so I'm guessing it would be fine under most circumstances otherwise we would have heard about it before.
Jean-Yves
2011/3/8 Jean-Yves Avenard jyavenard@gmail.com
On 7 March 2011 23:24, Raymond Yau superquad.vortex2@gmail.com wrote:
This seem to be bug in alsa-lib as I can reproduce using
alsa-lib/test/pcm.c
with buffer time 120000 and my hda codec support both 11025Hz and 22050Hz
using buffer time 160000 is OK
Yes.. It's hard to understand why 120ms wouldn't be okay, but 160ms would.
Could you check is 400ms works for you ? I found this to be a value that generally do not work when using 44.1kHz 6 channels audio.
For the time being, I made my application use 500ms buffer; this is what many media players are using (including mplayer) , so I'm guessing it would be fine under most circumstances otherwise we would have heard about it before.
Jean-Yves
It seem that hda-intel does not really has AZX_MAX_BUF_SIZE 1024x1024x1024 on 32bits machine , buffer bytes was reduced to 64K bytes at the beginning by "Rule 23"
Does linux kernel allow ALSA allocate 2/3 of system memory for sound buffer on a machine iwth 1.5Gbytes memory
64Kbytes is only 371ms of S16_LE 44100Hz stereo
ACCESS = 00000000ffffffffffffffff -> 0000000000000009 FORMAT = 00000000ffffffffffffffff -> 0000000000000404 SUBFORMAT = 00000000ffffffffffffffff -> 0000000000000001 SAMPLE_BITS = [0 4294967295] -> [0 4294967295] FRAME_BITS = [0 4294967295] -> [0 4294967295] CHANNELS = [0 4294967295] -> [2 8] RATE = [0 4294967295] -> [8000 192000] PERIOD_TIME = [0 4294967295] -> [0 4294967295] PERIOD_SIZE = [0 4294967295] -> [0 4294967295] PERIOD_BYTES = [0 4294967295] -> [128 536870912] PERIODS = [0 4294967295] -> [2 32] BUFFER_TIME = [0 4294967295] -> [0 4294967295] BUFFER_SIZE = [0 4294967295] -> [0 4294967295] BUFFER_BYTES = [0 4294967295] -> [128 1073741824] TICK_TIME = [0 4294967295] -> [0 4294967295] Rule 0 [f8ae36f2]: FORMAT = 404 -> 404 Rule 1 [f8ae351b]: SAMPLE_BITS = [0 4294967295] -> [16 32] Rule 2 [f8ae365f]: SAMPLE_BITS = [16 32] -> [16 32] Rule 3 [f8ae361d]: FRAME_BITS = [0 4294967295] -> [32 256] Rule 4 [f8ae35d9]: FRAME_BITS = [32 256] -> [32 256] Rule 5 [f8ae35d9]: FRAME_BITS = [32 256] -> [32 256] Rule 6 [f8ae365f]: CHANNELS = [2 8] -> [2 8] Rule 7 [f8ae35d9]: RATE = [8000 192000] -> [8000 192000] Rule 8 [f8ae35d9]: RATE = [8000 192000] -> [8000 192000] Rule 9 [f8ae365f]: PERIODS = [2 32] -> [2 32] Rule 10 [f8ae365f]: PERIOD_SIZE = [0 4294967295] -> [0 2147483647] Rule 11 [f8ae35d9]: PERIOD_SIZE = [0 2147483647] -> [4 134217728] Rule 12 [f8ae3595]: PERIOD_SIZE = [4 134217728] -> [4 134217728] Rule 13 [f8ae361d]: BUFFER_SIZE = [0 4294967295] -> [8 4294967295] Rule 14 [f8ae35d9]: BUFFER_SIZE = [8 4294967295] -> [8 268435456] Rule 15 [f8ae3595]: BUFFER_SIZE = [8 268435456] -> [8 268435456] Rule 16 [f8ae3595]: PERIOD_BYTES = [128 536870912] -> [128 536870912] Rule 17 [f8ae3595]: BUFFER_BYTES = [128 1073741824] -> [128 1073741824] Rule 18 [f8ae35d9]: PERIOD_TIME = [0 4294967295] -> (20 4294967295] Rule 19 [f8ae35d9]: BUFFER_TIME = [0 4294967295] -> (41 4294967295] Rule 20 [f8ae5fa6]: BUFFER_BYTES = [128 1073741824] -> [128 1073741824] Rule 21 [f8ae5fa6]: PERIOD_BYTES = [128 536870912] -> [128 536870912] Rule 22 [f8ae5fa6]: CHANNELS = [2 8] -> [2 8] Rule 23 [f8ae34e2]: BUFFER_BYTES = [128 1073741824] -> [128 65536] Rule 24 [f8ae34bd]: RATE = [8000 192000] -> [8000 192000]
At Tue, 8 Mar 2011 21:25:25 +0800, Raymond Yau wrote:
2011/3/8 Jean-Yves Avenard jyavenard@gmail.com
On 7 March 2011 23:24, Raymond Yau superquad.vortex2@gmail.com wrote:
This seem to be bug in alsa-lib as I can reproduce using
alsa-lib/test/pcm.c
with buffer time 120000 and my hda codec support both 11025Hz and 22050Hz
using buffer time 160000 is OK
Yes.. It's hard to understand why 120ms wouldn't be okay, but 160ms would.
Could you check is 400ms works for you ? I found this to be a value that generally do not work when using 44.1kHz 6 channels audio.
For the time being, I made my application use 500ms buffer; this is what many media players are using (including mplayer) , so I'm guessing it would be fine under most circumstances otherwise we would have heard about it before.
Jean-Yves
It seem that hda-intel does not really has AZX_MAX_BUF_SIZE 1024x1024x1024 on 32bits machine , buffer bytes was reduced to 64K bytes at the beginning by "Rule 23"
It's because of the pre-allocation buffer size. You can change it via proc file dynamically: echo 1024 > /proc/asound/card0/pcm0p/sub0/prealloc
Takashi
2011/3/8 Jean-Yves Avenard jyavenard@gmail.com
On 7 March 2011 23:24, Raymond Yau superquad.vortex2@gmail.com wrote:
This seem to be bug in alsa-lib as I can reproduce using
alsa-lib/test/pcm.c
with buffer time 120000 and my hda codec support both 11025Hz and 22050Hz
using buffer time 160000 is OK
Yes.. It's hard to understand why 120ms wouldn't be okay, but 160ms would.
Could you check is 400ms works for you ? I found this to be a value that generally do not work when using 44.1kHz 6 channels audio.
For the time being, I made my application use 500ms buffer; this is what many media players are using (including mplayer) , so I'm guessing it would be fine under most circumstances otherwise we would have heard about it before.
Jean-Yves
hda-intel.c only allocate 64Kbytes
/* buffer pre-allocation */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024);
user or distribution need to change "prealloc" from 64 to a higher value for getting 500ms buffer
echo 1024 > /proc/asound/Intel/pcm0p/sub0/prealloc
Hi
On Wednesday, 9 March 2011, Raymond Yau superquad.vortex2@gmail.com wrote:
hda-intel.c only allocate 64Kbytes
/* buffer pre-allocation */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024);
user or distribution need to change "prealloc" from 64 to a higher value for getting 500ms buffer
echo 1024 > /proc/asound/Intel/pcm0p/sub0/prealloc
It seems you misunderstood my first message.
For a start, the default memory allocated to alsa in ubuntu is 4096kB. so the amount of ram isn't the problem.
Setting a buffer of 200ms: ok 300ms: ok 400ms: not ok (invalid argument) 500ms: ok
Why would 400ms gives invalid argument, when 500ms doesn't nor 300. Memory available is obviously not the issue.
If only 64kB is allocated, requesting 200ms gives you 200ms 300ms -> 300ms 400ms -> invalid argument 500ms -> 371ms 600ms -> 371ms
You would assume that requesting 400ms would work or return what can fit in what has been pre-allocated.
Jy
On Wed, 9 Mar 2011, Jean-Yves Avenard wrote:
Hi
On Wednesday, 9 March 2011, Raymond Yau superquad.vortex2@gmail.com wrote:
hda-intel.c only allocate 64Kbytes
/* buffer pre-allocation */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024);
user or distribution need to change "prealloc" from 64 to a higher value for getting 500ms buffer
echo 1024 > /proc/asound/Intel/pcm0p/sub0/prealloc
It seems you misunderstood my first message.
For a start, the default memory allocated to alsa in ubuntu is 4096kB. so the amount of ram isn't the problem.
Setting a buffer of 200ms: ok 300ms: ok 400ms: not ok (invalid argument) 500ms: ok
Why would 400ms gives invalid argument, when 500ms doesn't nor 300. Memory available is obviously not the issue.
If only 64kB is allocated, requesting 200ms gives you 200ms 300ms -> 300ms 400ms -> invalid argument 500ms -> 371ms 600ms -> 371ms
You would assume that requesting 400ms would work or return what can fit in what has been pre-allocated.
What is your dir argument (last one) for the near functions? If it's NULL or value is zero, it means you request the exact value which may not be available. Use -1 to request specified or smaller value or 1 to request specified or bigger value.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
2011/3/9 Jaroslav Kysela perex@perex.cz
On Wed, 9 Mar 2011, Jean-Yves Avenard wrote:
Hi
On Wednesday, 9 March 2011, Raymond Yau superquad.vortex2@gmail.com wrote:
hda-intel.c only allocate 64Kbytes
/* buffer pre-allocation */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024);user or distribution need to change "prealloc" from 64 to a higher value for getting 500ms buffer
echo 1024 > /proc/asound/Intel/pcm0p/sub0/prealloc
It seems you misunderstood my first message.
For a start, the default memory allocated to alsa in ubuntu is 4096kB. so the amount of ram isn't the problem.
Setting a buffer of 200ms: ok 300ms: ok 400ms: not ok (invalid argument) 500ms: ok
Why would 400ms gives invalid argument, when 500ms doesn't nor 300. Memory available is obviously not the issue.
If only 64kB is allocated, requesting 200ms gives you 200ms 300ms -> 300ms 400ms -> invalid argument 500ms -> 371ms 600ms -> 371ms
You would assume that requesting 400ms would work or return what can fit in what has been pre-allocated.
What is your dir argument (last one) for the near functions? If it's NULL or value is zero, it means you request the exact value which may not be available. Use -1 to request specified or smaller value or 1 to request specified or bigger value.
Jaroslav
According to your explanation, it should fail at 500ms buffer time when rate is 11025Hz and dir=0 or NULL, since half of 11025 is 5512.5
but
alsa-lib/test/pcm -v -Dhw:CARD=Intel,DEV=0 -r 11025 -c 2 -b 500000
Playback device is hw:CARD=Intel,DEV=0 Stream parameters are 11025Hz, S16_LE, 2 channels Sine wave rate is 440.0000Hz Using transfer method: write Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 11025 exact rate : 11025 (11025/1) msbits : 16 buffer_size : 5504 period_size : 1376 period_time : 124807 tstamp_mode : NONE period_step : 1 avail_min : 1376 period_event : 0 start_threshold : 5504 stop_threshold : 5504 silence_threshold: 0 silence_size : 0 boundary : 1442840576 appl_ptr : 0 hw_ptr : 0
Hi
On 9 March 2011 23:29, Jaroslav Kysela perex@perex.cz wrote:
What is your dir argument (last one) for the near functions? If it's NULL or value is zero, it means you request the exact value which may not be available. Use -1 to request specified or smaller value or 1 to request specified or bigger value.
It is zero.
That still doesn't explain the difference in behaviour I'm seeing between 400ms or 500ms request. Neither of those are possible with a 64kB buffer.
What you are describing isn't what is happening in practice: Requesting 500ms with the dir=0 (or NULL) provides a buffer of 371ms. So it doesn't return an exact value, not even close (I found that with dir=0 or NULL always return a value equal or less than what is requested. If less the value returned is the maximum allowed by the prealloc value)
JY
2011/3/9 Jaroslav Kysela perex@perex.cz
On Wed, 9 Mar 2011, Jean-Yves Avenard wrote:
Hi
On Wednesday, 9 March 2011, Raymond Yau superquad.vortex2@gmail.com wrote:
hda-intel.c only allocate 64Kbytes
/* buffer pre-allocation */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024);user or distribution need to change "prealloc" from 64 to a higher value for getting 500ms buffer
echo 1024 > /proc/asound/Intel/pcm0p/sub0/prealloc
It seems you misunderstood my first message.
For a start, the default memory allocated to alsa in ubuntu is 4096kB. so the amount of ram isn't the problem.
Setting a buffer of 200ms: ok 300ms: ok 400ms: not ok (invalid argument) 500ms: ok
Why would 400ms gives invalid argument, when 500ms doesn't nor 300. Memory available is obviously not the issue.
If only 64kB is allocated, requesting 200ms gives you 200ms 300ms -> 300ms 400ms -> invalid argument 500ms -> 371ms 600ms -> 371ms
You would assume that requesting 400ms would work or return what can fit in what has been pre-allocated.
What is your dir argument (last one) for the near functions? If it's NULL or value is zero, it means you request the exact value which may not be available. Use -1 to request specified or smaller value or 1 to request specified or bigger value.
Take another example from alsa-lib/test
Try many parameters but still cannot let alsa-lib/test/latency.c work with alsa-pulse plugin and latency stop without any error message
alsa-lib/test/latency -P pulse -C pulse
adding some debug statement and find that it alway fail in setparams()
if (*bufsize > latency_max) { + printf("*bufsize %d > latency_max %d\n",*bufsize,latency_max); return -1; }
participants (4)
-
Jaroslav Kysela -
Jean-Yves Avenard -
Raymond Yau -
Takashi Iwai