GNOME Bugzilla – Bug 525833
[halaudiosrc] unable to get mic USB working with gnome-sound-properties
Last modified: 2008-04-05 12:00:22 UTC
I have to choose ALSA and "USB Audio" in order to get my USB microphone to work. With gstreamer-properties, the audiosrc is correctly set to alsasrc device="hw:1,0" which works great. In gnome-sound-properties however, I end up with this: halaudiosrc udi=/org/freedesktop/Hal/devices/usb_device_6f8_3005_noserial_if2_sound_card_0_alsa_capture_0 ...when chosing "USB Audio". Also, I get this output: sound-properties-Message: Error running pipeline 'gconfaudiosrc ! audioconvert ! audioresample ! gconfaudiosink profile=chat': Could not open audio device for recording. [gstalsasrc.c(640): gst_alsasrc_open (): /pipeline0/gconfaudiosrc0/bin1/halaudiosrc0/bin2/alsasrc0: Recording open error on device 'default:1': Invalid argument] The "default:1" should probably be "hw:1,0".
Created attachment 108502 [details] Screenshot
Created attachment 108503 [details] Screenshot #2 This shows the very confusing dropdown, which merges sound systems (ALSA or OSS, each using default card, which is not mentioned) and devices using specific sound systems (which again, are not mentioned): "USB Audio" (ALSA), "AD198x" (OSS). The selected choice is only available if I modify the audiosrc in gconf or use gstreamer-properties to change it.
Looks like a problem in halaudiosrc to me.
Well, why is the capplet using halaudiosrc in the first place? With alsasrc device="hw:1,0" (as set by the gstreamer-properties) it works fine.
Michael, could you attach the output of lshal? $ lshal > list.txt
Created attachment 108656 [details] lshal
(In reply to comment #5) > Michael, could you attach the output of lshal? Sure.
Right, this is caused by this code snippet in hal.c: if (device == 0) { /* handle default device specially to use * dmix, dsnoop, and softvol if appropriate */ string = g_strdup_printf ("%s device=default:%d", element, card); } else { string = g_strdup_printf ("%s device=plughw:%d,%d", element, card, device); } From bug #329106: "An additional change I've integrated is to use the "default:X" PCM/capture device instead of "plughw:X,Y" if device 0 is requested. This avoids the problem that dmix/dsnoop set-up by alsa-lib get ignored." It seems to me that this makes a lot of assumptions about the exact alsa setup, and is generally dodgy. DMix should be advertised as an option alongside direct hardware access instead of things being changed under the hood here. We can't assume that there's a default device set up or that it points to dmix. Anyway, I think the best quick-fix/hack is to only change the device string in the above way for playback devices, but not for capture devices: 2008-04-05 Tim-Philipp Müller <tim at centricular dot net> * ext/hal/hal.c: (gst_hal_get_alsa_element): Don't munge device string to 'default:x' for capture devices. Fixes #525833.