GNOME Bugzilla – Bug 590048
Change audio input device used in calls
Last modified: 2011-08-01 13:00:26 UTC
It should be possible to change the audio and video input devices used for a call. Ideally, we should be able to do this on-the-fly.
Created attachment 140149 [details] A mockup of the UI shown to the user when PulseAudio is installed. The string describing the device that would is shown to the user is the device description as reported by PulseAudio.
Created attachment 140150 [details] A mockup of the UI shown to the user when PulseAudio is not installed.
Branch which is in a work in progress state. It kinda works, but you have to have the gst-plugins-good patch posted for Bug 590768. I'm putting my work on this branch on hold until my gstreamer patch gets merged. http://git.collabora.co.uk/?p=user/jtellier/empathy.git;a=shortlog;h=refs/heads/change-device
Here's a branch: http://cgit.freedesktop.org/~jonny/empathy/log/?h=change-audio It relies on this pulsesrc patch: http://people.collabora.co.uk/~jonny/pulsesrc.txt Arun said he would try and get the patch merged to gst-plugins-good tonight or tomorrow or soon. This can easily be reviewed beforehand though.
Turns out the GstPulseSrc property will be renamed to source-output-index, so that change will have to be done once it's merged to good.
commit 8a937c926c79f24fdb36574cb036c9fc09532f3f audio-src: allow changing the audio source element Do we really want that? commit e2555e03c750ae0b6ffdf6a33fb2023563653244 Also listen out for changes in the source output ID (but that'll open happen if we go READY -> NULL -> READY again). open happen? commit b15789c383cb46f46e908f2eceed79310a243847 + if (state == PA_CONTEXT_READY) + { + /* Listen to pulseaudio events so we know when sources are + * added and when the microphone is changed. */ + pa_context_set_subscribe_callback (priv->context, + empathy_audio_src_pa_event_cb, self); + pa_context_subscribe (priv->context, + PA_SUBSCRIPTION_MASK_SOURCE | PA_SUBSCRIPTION_MASK_SOURCE_OUTPUT, + empathy_audio_src_pa_subscribe_cb, NULL); + } + + operations_run (self); Shouldn't you only call operations_run if state == PA_CONTEXT_READY ? (Iit's a no-op otherwise) + g_debug ("Failed to subscribe to PulseAudio events"); Make that a DEBUG commit c19588d7edf6336289d6fda98577f705a5a2e62c + if (error != NULL) + { + g_debug ("Failed to get microphone list: %s", error->message); + g_clear_error (&error); + return; + } DEBUG Why not g_error_free? error is != NULL Same in the other places The last commit doesn't build: empathy-mic-menu.c: In function ‘empathy_mic_menu_update’: empathy-mic-menu.c:207:15: error: ‘active’ undeclared (first use in this function) empathy-mic-menu.c:207:15: note: each undeclared identifier is reported only once for each function it appears in I wonder if all the microphone monitoring shouldn't be in a separate object, so that we can access it from empathy-preferences.c (a la EmpathyCameraMonitor). Then the selected microphone could live as a GSettings property. This also has the upside that we'll remember the microphone from one call to the other (or does PA do that for us?) Branch looks good otherwise.
(In reply to comment #6) > commit 8a937c926c79f24fdb36574cb036c9fc09532f3f > > audio-src: allow changing the audio source element > > Do we really want that? Sure, I sometimes want to use audiotestsrc instead. > commit e2555e03c750ae0b6ffdf6a33fb2023563653244 > Also listen out for changes in the source output ID (but that'll open > happen if we go READY -> NULL -> READY again). > > open happen? Heh, fixed. > commit b15789c383cb46f46e908f2eceed79310a243847 > > + if (state == PA_CONTEXT_READY) > + { > + /* Listen to pulseaudio events so we know when sources are > + * added and when the microphone is changed. */ > + pa_context_set_subscribe_callback (priv->context, > + empathy_audio_src_pa_event_cb, self); > + pa_context_subscribe (priv->context, > + PA_SUBSCRIPTION_MASK_SOURCE | PA_SUBSCRIPTION_MASK_SOURCE_OUTPUT, > + empathy_audio_src_pa_subscribe_cb, NULL); > + } > + > + operations_run (self); > > Shouldn't you only call operations_run if state == PA_CONTEXT_READY ? (Iit's a > no-op otherwise) Yeah, good point. Fixed. > + g_debug ("Failed to subscribe to PulseAudio events"); > > Make that a DEBUG Done. > commit c19588d7edf6336289d6fda98577f705a5a2e62c > > + if (error != NULL) > + { > + g_debug ("Failed to get microphone list: %s", error->message); > + g_clear_error (&error); > + return; > + } > > DEBUG Done. > Why not g_error_free? error is != NULL > > Same in the other places Actually I much prefer clear_error. It's no extra work and just ensures you're not going to be referencing freed memory in future if someone reworks the function a bit. > The last commit doesn't build: > > empathy-mic-menu.c: In function ‘empathy_mic_menu_update’: > empathy-mic-menu.c:207:15: error: ‘active’ undeclared (first use in this > function) > empathy-mic-menu.c:207:15: note: each undeclared identifier is reported only > once for each function it appears in Sorry about that! Fixed now. > I wonder if all the microphone monitoring shouldn't be in a separate object, so > that we can access it from empathy-preferences.c (a la EmpathyCameraMonitor). > Then the selected microphone could live as a GSettings property. This also has > the upside that we'll remember the microphone from one call to the other (or > does PA do that for us?) PA remembers the last microphone we used, so if you need to save the preferred microphone and have UI for it in Empathy there are two options here: 1. Look for API in PulseAudio (or get it added, which is easy enough tbh) to say "this is my preferred mic" so you don't have to save anything in Empathy and you just need to poll PA. 2. Save the favourite mic in some Empathy GSettings property and then set that when you start a call each time. I think option one is the best, no? Okay, I'll refactor the mic monitor stuff into another object because it'll be needed anyway for this even if we choose option one, but can we get this one merged first? :-) Thanks for the quick review!
(In reply to comment #7) > > I wonder if all the microphone monitoring shouldn't be in a separate object, so > > that we can access it from empathy-preferences.c (a la EmpathyCameraMonitor). > > Then the selected microphone could live as a GSettings property. This also has > > the upside that we'll remember the microphone from one call to the other (or > > does PA do that for us?) > > PA remembers the last microphone we used, so if you need to save the preferred > microphone and have UI for it in Empathy there are two options here: > > 1. Look for API in PulseAudio (or get it added, which is easy enough tbh) to > say "this is my preferred mic" so you don't have to save anything in Empathy > and you just need to poll PA. > > 2. Save the favourite mic in some Empathy GSettings property and then set that > when you start a call each time. > > I think option one is the best, no? Okay, I'll refactor the mic monitor stuff > into another object because it'll be needed anyway for this even if we choose > option one, but can we get this one merged first? :-) Yeah, let's merge this now and refactor it afterwards to add the necessary settings to the new Calls tab in empathy-preferences. Option 1 indeed sounds nicer.
18:55 < jonnylamb> pochu: http://cgit.freedesktop.org/~jonny/empathy/log/?h=change-audio 18:56 < jonnylamb> pochu: you probably already saw the second commit but the top one means we can merge this right now. Merge away!
Does this still depend on bug #590768 ? Does it mean that PA is now a requirement to do calls? Or we just need libpulse to be installed?
(In reply to comment #10) > Does this still depend on bug #590768 ? No, I removed the dependency. > Does it mean that PA is now a requirement to do calls? Or we just need libpulse > to be installed? We need PA to do calls now, because our audio device now defaults to pulsesrc.
How will this affect empathy-av? It will requier PA as well right? Any other change?
Yes. Merged.