[alsa-devel] crash with assertion (?)
hi all,
(just in case: sorry for double posting, i first sent from a non-subscribed address)
this might have been discussed already ages ago, but i didn't find much on the web, and i'm a bit confused why it happens, so:
i'm developing/bugfixing an application using (well, obviously) alsa, and i get crashes with assertions.
my setup: - nvidia CK804 onboard soundcard (this soundcard seems to only be able to run at 48kHz) - debian squeeze/sid (libasound2 1.0.23-1)
what i'm trying to do: i'm requesting my "plughw" device with 44100Hz the request is done with something like: rate=44100; err = snd_pcm_hw_params_set_rate_min(handle, params, &rate, 0); [...] err = snd_pcm_hw_params(handle, params);
what happens: in the snd_pcm_hw_params(), my program exits with: "interval_inline.h:52: snd_interval_single: Assertion `!snd_interval_empty(i)' failed."
sidenotes: if i use the "hw" device, i get away with the wrong samplerate (no crash, though the requested samplerate does not take effect)
now i understand, that my soundcard does not accept 44100Hz. what i don't understand is, that alsa-lib crashes with an assertion error. i expect snd_pcm_hw_params() return an error!=0 if it fails to do what it is asked to do. imho, a library should _never ever_ crash the application.
is this a bug? in alsa-lib? in the debian-packages?
fgmasdr IOhannes
On 2010-09-07 18:05, IOhannes m zmoelnig wrote:
hi all,
is this a bug? in alsa-lib? in the debian-packages?
it seems like debian compiles the package without explicitely adding the "--without-debug" configure-flag, does resulting in assert()ions that exist the application.
i will file a bug-report with debian, so they can fix this.
in the meantime: why is it the default to compile with asserts?
fgamdf IOhannes
On 2010-09-07 18:07, IOhannes m zmoelnig wrote:
it seems like debian compiles the package without explicitely adding the "--without-debug" configure-flag, does resulting in assert()ions that exist the application.
i will file a bug-report with debian, so they can fix this.
in the meantime: why is it the default to compile with asserts?
but obviously the assertion is there for a reason (so i guess i would get crashes even if the assertion was not there, since the assert() only protects from a NULL-pointer dereferencing)
which brings the bug back to alsa-lib....
fgamsdr IOhannes
IOhannes m zmoelnig wrote:
i'm requesting my "plughw" device with 44100Hz the request is done with something like: rate=44100; err = snd_pcm_hw_params_set_rate_min(handle, params, &rate, 0);
This requests a sample rate of at least 44100 Hz.
[...] err = snd_pcm_hw_params(handle, params);
what happens: in the snd_pcm_hw_params(), my program exits with: "interval_inline.h:52: snd_interval_single: Assertion `!snd_interval_empty(i)' failed."
You called snd_pcm_hw_params with an invalid params structure. I'd guess that snd_pcm_hw_params_set_rate_min (or some other snd_pcm_hw_params_set_*) returned an error.
Regards, Clemens
On 2010-09-07 19:06, Clemens Ladisch wrote:
IOhannes m zmoelnig wrote:
i'm requesting my "plughw" device with 44100Hz the request is done with something like: rate=44100; err = snd_pcm_hw_params_set_rate_min(handle, params, &rate, 0);
This requests a sample rate of at least 44100 Hz.
yes. this is good enough for me. (it shouldn't crash though)
[...] err = snd_pcm_hw_params(handle, params);
what happens: in the snd_pcm_hw_params(), my program exits with: "interval_inline.h:52: snd_interval_single: Assertion `!snd_interval_empty(i)' failed."
You called snd_pcm_hw_params with an invalid params structure. I'd guess that snd_pcm_hw_params_set_rate_min (or some other snd_pcm_hw_params_set_*) returned an error.
i wish you were right. however, it seems like i am blindfolded.
i noticed however, that i need to set both the rate (i use snd_pcm_hw_params_set_rate_min()) and the period size (i use snd_pcm_hw_params_set_period_size_near()), in order to make it crash.
attached is an example code that triggers the crash. please someone shed some light...
gmasdr IOhannes
PS: that's how i use the sample program: $ gcc -o alsatest alsatest.c $(pkg-config --cflags --libs alsa) $ ./alsatest trying to open 'hw:0' as CAPTURE configuring device succeeded CAPTURE configured trying to open 'hw:0' as PLAYBACK configuring device succeeded PLAYBACK configured trying to open 'plughw:0' as CAPTURE configuring device succeeded CAPTURE configured trying to open 'plughw:0' as PLAYBACK alsatest: interval_inline.h:55: snd_interval_single: Assertion `!snd_interval_empty(i)' failed. Aborted
so it seems to work fine with "hw:0" but not with "plughw:0".
you can specify the device to be opened on the cmdline: $ ./alsatest hw:2
2010/9/8 IOhannes m zmoelnig zmoelnig@iem.at
On 2010-09-07 19:06, Clemens Ladisch wrote:
IOhannes m zmoelnig wrote:
i'm requesting my "plughw" device with 44100Hz the request is done with something like: rate=44100; err = snd_pcm_hw_params_set_rate_min(handle, params, &rate, 0);
This requests a sample rate of at least 44100 Hz.
yes. this is good enough for me. (it shouldn't crash though)
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h...
Restrict a configuration space with a minimum rate.
val approximate minimum rate ( on return filled with actul minimum ) dir sub unit direction (on return filled with actual direction)
Return 0 otherwise a negative error code if configuration space would become empty
what is the minimum rate returned by snd_pcm_hw_params_get_rate_min() when using hw:0,0 ?
[...] err = snd_pcm_hw_params(handle, params);
what happens: in the snd_pcm_hw_params(), my program exits with: "interval_inline.h:52: snd_interval_single: Assertion `!snd_interval_empty(i)' failed."
You called snd_pcm_hw_params with an invalid params structure. I'd guess that snd_pcm_hw_params_set_rate_min (or some other snd_pcm_hw_params_set_*) returned an error.
i wish you were right. however, it seems like i am blindfolded.
i noticed however, that i need to set both the rate (i use snd_pcm_hw_params_set_rate_min()) and the period size (i use snd_pcm_hw_params_set_period_size_near()), in order to make it crash.
attached is an example code that triggers the crash. please someone shed some light...
gmasdr IOhannes
PS: that's how i use the sample program: $ gcc -o alsatest alsatest.c $(pkg-config --cflags --libs alsa) $ ./alsatest trying to open 'hw:0' as CAPTURE configuring device succeeded CAPTURE configured trying to open 'hw:0' as PLAYBACK configuring device succeeded PLAYBACK configured trying to open 'plughw:0' as CAPTURE configuring device succeeded CAPTURE configured trying to open 'plughw:0' as PLAYBACK alsatest: interval_inline.h:55: snd_interval_single: Assertion `!snd_interval_empty(i)' failed. Aborted
so it seems to work fine with "hw:0" but not with "plughw:0".
you can specify the device to be opened on the cmdline: $ ./alsatest hw:2
To debug , you will need to enable RULES_DEBUG In pcm_params.c
add snd_pcm_dump() after snd_pcm_hw_params in your program
export LIBASOUND_DEBUG=1
and post the output of your program
On 2010-09-09 03:30, Raymond Yau wrote:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h...
l
what is the minimum rate returned by snd_pcm_hw_params_get_rate_min() when using hw:0,0 ?
for hw:0,0 it is 48000, direction=0 for plughw:0,0 i get 4000(sic!), direction=0
To debug , you will need to enable RULES_DEBUG In pcm_params.c
add snd_pcm_dump() after snd_pcm_hw_params in your program
export LIBASOUND_DEBUG=1
and post the output of your program
ok, i tried that. there's of course the little problem with havind snd_pcm_dump() after snd_pcm_hw_params(), since the latter crashes... so i added it before i start configuring the device as well. here's the pseudocode: <snip> open(PLAYBACK); dump(); nonblock(1); get_rate(); set_rate(44100); set_period(64); dump(); close(); open(CAPTURE); dump(); nonblock(1); get_rate(); set_rate(44100); set_period(64); /* CRASH */ dump(); close(); </snip>
i prefixed all the printout of my application with "JMZ", so you can easily filter it out.
fgmasdr IOhannes
2010/9/9 IOhannes m zmoelnig zmoelnig@iem.at
On 2010-09-09 03:30, Raymond Yau wrote:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h... l
what is the minimum rate returned by snd_pcm_hw_params_get_rate_min()
when
using hw:0,0 ?
for hw:0,0 it is 48000, direction=0 for plughw:0,0 i get 4000(sic!), direction=0
Are there any reason which you need to use snd_pcm_hw_params_set_rate_min() instead of snd_pcm_hw_params_set_rate_near() ?
set_rate_min( 44100) only restrict a configuration space with a minimum rate and this is not sufficient for alsa-lib to refine the parameters of snd_pcm_hw_params() to unique value when the device is plughw and your sound card only support 48000Hz and 96000Hz
Yes, I can reprodued the assertion with a patched intel8x0 driver inside virtualbox since there is no error when using the emulated ac97 controller and codec which support 8000Hz<->48000Hz
There is no error when change to use set_rate_near instead of set_rate_min
To debug , you will need to enable RULES_DEBUG In pcm_params.c
add snd_pcm_dump() after snd_pcm_hw_params in your program
export LIBASOUND_DEBUG=1
and post the output of your program
ok, i tried that. there's of course the little problem with havind snd_pcm_dump() after snd_pcm_hw_params(), since the latter crashes... so i added it before i start configuring the device as well. here's the pseudocode:
<snip> open(PLAYBACK); dump(); nonblock(1); get_rate(); set_rate(44100); set_period(64); dump(); close(); open(CAPTURE); dump(); nonblock(1); get_rate(); set_rate(44100); set_period(64); /* CRASH */ dump(); close(); </snip>
i prefixed all the printout of my application with "JMZ", so you can easily filter it out.
fgmasdr IOhannes
schange 'plughw:0,0' (slave) ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: [32 128] CHANNELS: [2 8] RATE: [48000 96000] PERIOD_TIME: (20 341334) PERIOD_SIZE: [2 16384] PERIOD_BYTES: [32 131072] PERIODS: [1 1024] BUFFER_TIME: (20 341334) BUFFER_SIZE: [2 16384] BUFFER_BYTES: [32 65536] TICK_TIME: ALL ALSA ERROR hw_params: set (RATE) value = 44100 : Invalid argument ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: [32 128] CHANNELS: [2 8] RATE: [48000 96000] PERIOD_TIME: (20 341334) PERIOD_SIZE: [2 16384] PERIOD_BYTES: [32 131072] PERIODS: [1 1024] BUFFER_TIME: (20 341334) BUFFER_SIZE: [2 16384] BUFFER_BYTES: [32 65536] TICK_TIME: ALL ALSA ERROR hw_params: set (RATE) value = 88200 : Invalid argument ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: [32 128] CHANNELS: [2 8] RATE: [48000 96000] PERIOD_TIME: (20 341334) PERIOD_SIZE: [2 16384] PERIOD_BYTES: [32 131072] PERIODS: [1 1024] BUFFER_TIME: (20 341334) BUFFER_SIZE: [2 16384] BUFFER_BYTES: [32 65536] TICK_TIME: ALL srefine 'plughw:0,0' (client) ACCESS: MMAP_INTERLEAVED FORMAT: S8 SUBFORMAT: STD SAMPLE_BITS: 8 FRAME_BITS: 8 CHANNELS: 1 RATE: [44100 44100] PERIOD_TIME: (83 1452) PERIOD_SIZE: 64 PERIOD_BYTES: 64 PERIODS: (0 4113) BUFFER_TIME: (3 5968186) BUFFER_SIZE: [3 263197] BUFFER_BYTES: [3 263197] TICK_TIME: ALL srefine 'plughw:0,0' (slave) ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (166 1452) PERIOD_SIZE: [8 16384] PERIOD_BYTES: [32 65536] PERIODS: [1 1024] BUFFER_TIME: (166 341334) BUFFER_SIZE: [8 16384] BUFFER_BYTES: [32 65536] TICK_TIME: ALL cchange 'plughw:0,0'
The assertion occur becacuse RATE=44100 -> NONE
Rule 5 (0xb7773aa0): FRAME_BITS=8 -> 8 BUFFER_BYTES=[3 263197] BUFFER_SIZE=[7 15052] Rule 7 (0xb7773aa0): RATE=44100 -> NONE PERIOD_SIZE=64 PERIOD_TIME=(166 1438)
alsatest: interval_inline.h:52: snd_interval_single: Assertion `!snd_interval_empty(i)' failed.
Raymond Yau wrote:
Yes, I can reprodued the assertion with a patched intel8x0 driver inside virtualbox since there is no error when using the emulated ac97 controller and codec which support 8000Hz<->48000Hz
How exactly did you patch it?
Rule 7 (0xb7773aa0): RATE=44100 -> NONE PERIOD_SIZE=64 PERIOD_TIME=(166 1438)
alsatest: interval_inline.h:52: snd_interval_single: Assertion `!snd_interval_empty(i)' failed.
This looks like a definite bug.
Regards, Clemens
2010/9/10 Clemens Ladisch clemens@ladisch.de
Raymond Yau wrote:
Yes, I can reprodued the assertion with a patched intel8x0 driver inside virtualbox since there is no error when using the emulated ac97 controller and codec which support 8000Hz<->48000Hz
How exactly did you patch it?
based on his log and his card seem support rate 48000 and 96000 only
SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_96000
the assertion also occur with snd-dummy model=ac97 with the above change in rate constraint on Fedora 13
may need the output of alsa-info.sh to find out his ac97 codec and snd_pcm_dump to find out the resampler
participants (3)
-
Clemens Ladisch -
IOhannes m zmoelnig -
Raymond Yau