GNOME Bugzilla – Bug 341983
gstreamer-properties should allow selection of default input/output soundcard
Last modified: 2006-12-19 15:31:48 UTC
I suggest that gstreamer-properties should allow selection of the "device" property of alsasink/osssink in a intuitive and HIG compliant way. Right now the "default" output device is used, however there are several scenarios where users have additional soundcards (especially headsets/usb, onboard vs. additional high-quality soundcard). It would be good if gstreamer-properties would list all "soundcard-devices" available for the sink/src and allow choosing one or keep this at "default". This comes handy if you want to switch/mix your input/output audio setups (headset mic input/soundcard ouput and any combination). The plugins already support a "device" property in gst however I don't know how you query for all devices available on the system, how this "normilizes" with the other audio plugins that do not have such abilities, the "video" tab and what the best UI representation would look like (prolly add. dynamic pulldowns and do what the volume control does to list devices?). Example: In my particular case I have one on-board, an additional soundcard and an USB-headset. At times I like to switch all output to the USB-headset. If I would be the average user joe, I would not know how to create my custom pipeline and choose a cryptic hw-plug etc. devicename. My "search" for that feature would certainly end at gstreamer-properties though.
Ok just noted that there are a couple of (aged!) duplicates for this functionality... So I did some more research. The gst-recorder actually renamed to cupid project in GNOME CVS. The interesting part is in /cupid/src/list.c:gst_rec_list_any_sources(...) It basicly: - Creates a test element of the selected sink/src - Checks for a "device" property - Probes a list of "device" possibilities - Assigns these to the test element to read the full "device-name" property In todo-terms: - Add two listboxes labeled "Device" in the Audio tab - Populating Device listboxes with the devices (if any available for the sink/src) - Construct the appropriate pipeline part I'll maybe try to give it a go myself...
Created attachment 65731 [details] [review] Adds device selection for editors, not final, test-patch * Add new device option menus to interface * Populate device menus if selected editor element supports probing * Add device selection and ability to use it in the test pipeline * Depends on patch in Bug 342181 for gst-plugins-base adding alsa probing Left Todo: - Correctly pre-select devicemenu and optionmenu depending on gconf data - Fix issue with test pipelines (some devices fail with odd rate error?) - Test device selection on video[sink|src] - Why does it get "USB Audio" instead of "Plantronics Headset" like the mixer? - Check for leaks This is a work-in-progress patch to (maybe) get some feedback, also on how the videoelement device stuff is doing if anyone is able to test. The main device probing code is from Ronald Bultje's cupid (gst-rec). In gst-0.10, probing interfaces are not implemented aside the mixer elements. Therefore this change dependents on a pending patch on Bug 342181 for gst-plugins-base. Please mind I am not very experienced in coding in this area and appreciate any hints/feedback.
- Now depends on Bug 342494 aswell, if fixed, video device selection works too - Test pipelines issue is fixed (latest GStreamer CVS solved it) - "USB Audio" vs "Plantronics Headset" is all correct, happens due to quering playback/capture vs. mixer devices. Left Todo: - Correctly pre-select devicemenu and optionmenu depending on gconf data - Some devices do not appear in menu if they are in use - Check for leaks (- Add property probing to GStreamer oss elements) (- Asynchronous probing)
*** Bug 141449 has been marked as a duplicate of this bug. ***
I really like this, any updates on this?
I did not have much time reecently to work on this and the blocking video bug patch has not yet been accepted. Anyways, what I noted with my working copy is that the GStreamer "PropertyProbing-Way" always probes all devices which can add an unpleasent delay in some elements (v4l cards), lacks user experience and can easily introduce concurency issues. Recently gnome-sound-properties implemented a way to select devices by using HAL to determine all devices with "alsa" capabilities, which points into the right direction. I have posted the explaination of the issues and my proposal for GST here (basicly we need "hal[audio|video|mixer][sink|src]" GST elements): http://sourceforge.net/mailarchive/forum.php?thread_id=19627530&forum_id=5947 In general, I now conclude that the capplet should use purely HAL to determine devices which would work on-the-fly and not introduce any blocking/delays. For now, I am going to talk to Tim again and am sure the remaining blocking bug will be fixed. Afterwards I finish this patch's remaining todo's and move to a different approach using purely HAL.
v4lsrc has disable-* properties, which you can set to true to omit the blocking steps. For probing, you can simply do a g_object_class_has_property() on each element you're probing, and then set all disable-* to true.
Created attachment 69013 [details] [review] Add device selection to gstreamer-properties (audio/video) * Adds new device option menus to interface * Populate device menus if selected editor element supports probing * Add device selection and ability to use it in the test pipeline * Sets device correctly from prior gconf setting Notes: - Diff is on latest CVS Head - Still depends on Bug 342494 for video devices to make probing work for the v4l [2] elements (should be committed soon) - A device won't be listed while in use (looks like an ALSA issue on first look) --- "v4lsrc has disable-* properties" What do you mean? I could not find these properties in the v4l sources at all. With "blocking" I was talking about the v4l property probing code to query the v4l devices and introduce a "delay" when the OptionMenu is being filled with devices. This could be avoided with HAL all together since it is "static list" vs. "probing hardware devices". For now the patch should fulfill the requirements of my initial bugreport.
autoprobe and autoprobe-fps -> FALSE.
Created attachment 69056 [details] [review] Add device selection to gstreamer-properties (audio/video) * Adds new device option menus to interface * Populate device menus if selected editor element supports probing * Add device selection and ability to use it in the test pipeline * Sets device correctly from prior gconf setting * Sets "autoprobe[-fps]" properties to FALSE if available to avoid delays Thanks! The autoprobing disabled did have quite some impact for me so the devices got listed fluently (guess my old webcam delays with that fps code). Looks like this now: http://www.sukimashita.com/temp/gstp-video.png http://www.sukimashita.com/temp/gstp-audio.png
Created attachment 69383 [details] [review] Add device selection to gstreamer-properties (audio/video) * Change caption of UI labels to comply with changes (Default Output:/Plugin:) * Adds new device option menus to interface * Populate device menus if selected editor element supports probing * Add device selection and ability to use it in the test pipeline * Sets device correctly from prior gconf setting * Sets "autoprobe[-fps]" properties to FALSE if available to avoid delays
Beautiful, exactly what I wanted. Let's pply this after the feature freeze (2.16).
Can someone comment on the status of this? I really like to see it committed for 2.18.
It would be good to either commit or close this bug which is based on years old bugs ;) I don't know what the usual process is but I think the overall multimedia/sound functionality in the GNOME desktop could require some revision (coffeetalk).
Finally got this in after hand tweaking some bits in pipeline-constants.c. Thanks a lot for your work. We really appreciate it even though it took some time to get it commited.