GNOME Bugzilla – Bug 121507
ALSA back-end can't set up device
Last modified: 2004-12-22 21:47:04 UTC
I get the following error when attempting to run any gstreamer apps with the ALSA backend; for example: ############ 15:25:44 > gst-launch-0.6 sinesrc ! alsasink INFO (17142: 0) Initializing GStreamer Core Library version 0.6.2 INFO (17142: 0) CPU features: (00000000) MMX SSE INFO (17142: 0) registry: loaded user_registry in 0.225773 seconds (/home/smandal/.gstreamer/registry.xml) INFO (17142: 0) registry: loaded global_registry in 0.296011 seconds (/var/lib/cache/gstreamer-0.6/registry.xml) GStreamer-INFO: 0 live buffer(s) GStreamer-INFO: 0 live bufferpool(s) GStreamer-INFO: 0 live event(s) RUNNING pipeline Opening alsa device "default" for playback... Preparing channel: (null) 44100Hz, 2 channels ALSA lib pcm_hw.c:370:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS failed: Invalid argument ** (process:17142): WARNING **: could not set sw_params: Invalid argument pipeline doesn't want to play GStreamer-INFO: 0 live buffer(s) GStreamer-INFO: 0 live bufferpool(s) GStreamer-INFO: 0 live event(s) ############### My specific info: alsa-* = 0.9.6 gstreamer = 0.6.2 gst-plugins = 0.6.2 Regards, Sourav
I'm seeing this as well, with GStreamer 0.6.3-1 RPM's on 2.6.0-0.test4.1.33 arjan's 9.0 rpms. Same alsa-lib. Not sure if it's helpful, but commenting out the snd_pcm_sw_params_set_silence_size call changes the error to: (process:8162): GStreamer-CRITICAL **: file gstprops.c: line 1001 (gst_props_get_entry): assertion `props != NULL' failed (process:8162): GStreamer-CRITICAL **: file gstprops.c: line 1164 (gst_props_entry_get_safe): assertion `entry != NULL' failed I'm compiling 7.0 to find out if the behavior continues, as I see gstalsa.c has been reworked. I'm using snd-maestro3 on a Dell laptop.
Fixed for me in cvs. (Did have a bit of trouble with the initial gst-register, but only as I was under the impression it did not need root. gst-register created /root/.gstreamer-0.7/registry.xml, so I moved it to ~user/.gstreamer-0.7/. I suppose there are some docs somewhere explaining this...) gstalsa plays fine for me now.
Ok, thanks -- I'll try out gstreamer 0.7 when it's released, and hopefully it'll work for me. BTW, I'm on a Compaq Presario 2800T (ca. June '02), which uses an intel8x0.
*** Bug 125164 has been marked as a duplicate of this bug. ***
*** Bug 123904 has been marked as a duplicate of this bug. ***
Will this bug be fixed for 0.6.x? This makes gstreamer based apps unusable for a lot of people if you don't have oss emulation working.
And the OSS emulation skips sound for me (VIA82xxx), so it's not a choice :\
FYI, Mdk bug report similar to this one : http://qa.mandrakesoft.com/show_bug.cgi?id=6276
in fedora core 1, kernel-2.4.22-1.2129.nptl, alsa-driver,alsa-lib, alsa-utils-1.0.0-0.rc2.1.fr kernel-module-alsa-1.0.0-0.rc2.1.fr_2.4.22_1.2129.nptl Ouput ALSA - Advanced Linus Sound Architecture in gstreamer-properties No Sound,and print error messages ----------------------- INFO (23620: 0) registry: loaded global_registry in 0.187662 seconds (/var/cache/gstreamer-0.6/registry.xml) Opening alsa device "default" for playback... Preparing channel: (null) 44100Hz, 2 channels ALSA lib pcm_hw.c:370:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS failed: Invalid argument ** (gstreamer-properties:23620): WARNING **: could not set sw_params: Invalid argument Opening alsa device "default" for playback... Preparing channel: (null) 44100Hz, 2 channels ALSA lib pcm_hw.c:370:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS failed: Invalid argument ** (gstreamer-properties:23620): WARNING **: could not set sw_params: Invalid argument Opening alsa device "default" for playback... Preparing channel: (null) 44100Hz, 2 channels ALSA lib pcm_hw.c:370:(snd_pcm_hw_sw_params) SNDRV_PCM_IOCTL_SW_PARAMS failed: Invalid argument ** (gstreamer-properties:23620): WARNING **: could not set sw_params: Invalid argument
Also a problem in Debian sid for me, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228349
This is fixed in 0.7.x for quite some time now (as reported somewhere up here), and will not be fixed in the 0.6.x series. Sorry.