Reproducers:
1. After a fresh install of Ubuntu 20.04, open a gnome-terminal
and press the Tab key, the system will output a bell notification
sound. Open gnome-control-center and check the sound page,
the output volume of 'System Sounds' is at 0, but the notification
sound is still output at max volume.
2. After a fresh install of Ubuntu 20.04, open gnome-control-center
directly, change to the sound page, the output volume of
'System Sounds' is at its max level. Click any 'Alert Sound' button
at the bottom of the page, the sound is output at max volume but
the UI slider for the output volume of 'System Sounds' changes to 0.
The notification sound can however still could be heard at max volume.
After a fresh install of the system, there is no saved entry for
"sink-input-by-media-role:event" in PulseAudio's module-stream-restore,
so libgvc will create a pa_ext_stream_restore_info in the
_pa_ext_stream_restore_read_cb(). When a notification sound stream
is sent to PA, PA will create an entry with name of
"sink-input-by-media-role:event" and save it to the database, but
volume_valid is false until gnome calls pa_ext_stream_restore_write().
So if users open the gnome-control-center before
pa_ext_stream_restore_write() is called, although there is an entry
named "sink-input-by-media-role:event" in the module-stream-restore,
the volume is not valid in that entry, and calling
pa_cvolume_max (&info->volume) will returns 0.
In this case, libgvc reports the max_volume is 0, but in PulseAudio,
the stream/sink-input volume is max (pa_sink_input_new() of the
sink-input.c).
Check if info->volume.channels is 0, which would mean the volume is
not valid in the entry, and set max_volume to PA_VOLUME_NORM like
_pa_ext_stream_restore_read_cb() does in this case.
Below is the PA log about the stream entry without a valid volume:
E: [pulseaudio] module-stream-restore.c: name=sink-input-by-media-role:event
E: [pulseaudio] module-stream-restore.c: device=(null) no
E: [pulseaudio] module-stream-restore.c: channel_map=(invalid)
E: [pulseaudio] module-stream-restore.c: volume=(invalid) no
E: [pulseaudio] module-stream-restore.c: mute=no no
Keep track of the `GParamSpec`s of the properties. This allows us to use
`g_object_notify_by_pspec()`, which is a bit more performant than
`g_object_notify()`(as it doesn't need to take a global lock to lookup
the property name). It also prevents accidental typos in the property
name at compile time.
Also always add `G_PARAM_STATIC_STRINGS`, to prevent some unnecessary
string duplications of property name, blurb and description.
Apart from being less code, this actually gives us a tiny performance
improvement. Up until a few years ago, if you pass `NULL` as the
marshaller for a signal, GLib would fall back to
`g_cclosure_marshal_generic` which uses libffi to pack/unpack its
arguments. One could avoid this by specifying a more specific
marshaller which would then be used to immediately pack and unpack into
GValues with the correct type.
Lately however, as a way of optimizing signal emission (which can be
quite expensive), GLib added a possibility to set a `va_marshaller`,
which skips the unnecessary GValue packing and unpacking and just uses a
valist variant.
Since the performance difference is big enough, if the marshaller
argument is NULL, `g_signal_new()` will now check for the simple
marshallers (return type NONE and a single argument) and set both the
generic and the valist marshaller. In other words, less code for us with
behind-the-scenes optimizations.
In case you also want va_marshallers for more complex signals, you can
use `g_signal_set_va_marshaller()`.
subprojects/gvc/gvc-mixer-control.c:1325:22: warning: variable 'stream_port_count' set but not used [-Wunused-but-set-variable]
gint stream_port_count = 0;
^
GvcMixerCards are not removed when reconnecting to PA server, which
causes duplicate card entries to appear on PA restart. Moreover, the
old GvcMixerCard instances have pointers to the old already freed
pa_context, resulting to use-after-free on operations. Duplicate
entries are also caused by sink/source removal on reconnect not sending
right signals.
Make it clean up all Gvc objects as if we got subscribe remove events
for them all:
Use remove_sink/remove_source to remove sinks/sources so that the right
signals are emitted. Remove cards using remove_card, so that also they
get cleaned up. Remove also any leftover GvcMixerUIDevices.
Move cleanup of streams etc. before pa_context unref, so that we free
the objects referring the pa_context before freeing the context.
This fixes gnome-control-center crashing when PA server is restarted,
and one e.g. tries to do something that ends up in
gvc_mixer_card_change_profile such as selecting output device with port
in different profile. It also fixes duplicate entries appearing in the
device lists on Pipewire restart (they don't appear with Pulseaudio
since PA device IDs don't change on restart).
It should also fix similar crashes in gnome-shell.
In update_card, profile_list is incorrectly used also after its
ownership is transferred to the GvcMixerCard. In practice, this causes
e.g. some profiles to go missing due to the list head being clobbered.
Fix this by calling gvc_mixer_card_set_profiles only after profiles_list
is no longer used for any other purpose.
Some devices don't have a card to match against, (e.g. network sinks),
which would make 'match_stream_with_devices()' get confused and log
warnings about missing card devices when trying to match streams with
devices.
Avoid this by marking a stream as 'in-possession' if there was already a
device with the stream ID set to it.
This fixes warning like
(gnome-shell:3521215): Gvc-CRITICAL **: 10:57:07.155: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
It is a bad idea to use the variable port name to check the port
type. Use only the new port type and availability group string
for the decision.
Also, select the ports by priority, if there multiple ports
with the similar type.
Recently Intel added a new audio driver in the Linux kernel, it is
called sof driver. This driver is needed on the laptops which
connects the digital mic to the PCH instead of the codec. To make the
sof driver work with pulseaudio, the ucm is mandatory.
With the ucm, the multi-function audio jack has different port names
in the pulseaudio from the one without ucm, these are the port names
with the ucm:
[In] Mic1: Digital Microphone
[In] Mic2: Headphones Stereo Microphone
[In] Headset: Headset Mono Microphone
[Out] Headphones: Headphones
[Out] Speaker: Speaker
To make the audio device selection work on the machines using the ucm,
the pulseaudio introduces a change to add 2 new members in the device
port structure from the PA_PROTOCOL_VERSION=34, with these 2 members'
help, we could consolidate the port finding and setting for both with
ucm and without ucm.
And this patch maintains the backward compatibility with the
PA_PROTOCOL_VERSION < 34.
Warnings introduced in ec5cf3e0de:
gvc-mixer-control.c:1457:9: warning: enumeration value ‘PA_SINK_INIT’ not handled in switch [-Wswitch-enum]
gvc-mixer-control.c:1457:9: warning: enumeration value ‘PA_SINK_UNLINKED’ not handled in switch [-Wswitch-enum]
Warning building with alsa:
gvc-mixer-control.c:2218:9: warning: enumeration value ‘GVC_HEADSET_PORT_CHOICE_NONE’ not handled in switch [-Wswitch-enum]
When on A2DP profile and a Bluetooth input is selected, we first need to
switch the profile to HFP/HSP, then select the default source to be that
profile. In some cases the latter step was forgotten, because
the variable "profile_swapping_device_id" was reset before it was
supposed to be used.
https://bugzilla.gnome.org/show_bug.cgi?id=736943
In both cases objects are inserted in hash table by adding an
extra ref, but the existing reference was never removed. Don't
add a reference instead, so we don't end up with a spare one.
Based on patch by Alberts Muktupāvels <alberts.muktupavels@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765694
In a28e23d900, we said:
The callbacks will be called repeatedly, once with data, and later
on with eol == 0. Make sure to only free it when we get the eol call
instead of once we've applied the settings.
Whereas the docs say:
When requesting all of these [instances] at once, the callback will be
called multiple times, once for each object. When the list has been
exhausted, the callback will be called without an information structure
and the eol parameter set to a positive value.
If an error occurs, the callback will be invoked without an information
structure and eol set to a negative value.
So, in all, we need to free our callback data when eol is positive, or
negative. So, when it's not 0.
Seems we got lucky in the original commit because the test machine only
had a single soundcard.
The callbacks will be called repeatedly, once with data, and later
on with eol == 0. Make sure to only free it when we get the eol call
instead of once we've applied the settings.
Example valgrind output:
==31715== Invalid read of size 8
==31715== at 0x24529E09: port_status_data_free (gvc-mixer-control.c:2079)
==31715== by 0x1DB81344: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF3FE0: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF436A: pa_pdispatch_run (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DB7507D: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF6B5E: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF91BA: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9568: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9DF9: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1D96202A: ??? (in /usr/lib64/libpulse-mainloop-glib.so.0.0.5)
==31715== by 0x7AA7CF9: g_main_dispatch (gmain.c:3154)
==31715== by 0x7AA7CF9: g_main_context_dispatch (gmain.c:3769)
==31715== by 0x7AA8057: g_main_context_iterate.isra.29 (gmain.c:3840)
==31715== Address 0x2bd83480 is 0 bytes inside a block of size 16 free'd
==31715== at 0x4C2ED6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31715== by 0x7AAD2AD: g_free (gmem.c:189)
==31715== by 0x1DB81562: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF3FE0: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF436A: pa_pdispatch_run (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DB7507D: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF6B5E: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF91BA: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9568: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9DF9: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1D96202A: ??? (in /usr/lib64/libpulse-mainloop-glib.so.0.0.5)
==31715== by 0x7AA7CF9: g_main_dispatch (gmain.c:3154)
==31715== by 0x7AA7CF9: g_main_context_dispatch (gmain.c:3769)
==31715== Block was alloc'd at
==31715== at 0x4C2F9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31715== by 0x7AAD1F0: g_malloc0 (gmem.c:124)
==31715== by 0x2452A39D: gvc_mixer_control_set_port_status_for_headset (gvc-mixer-control.c:2173)
==31715== by 0x2451BE81: audio_selection_done (gsd-media-keys-manager.c:2489)
==31715== by 0x7550ED3: emit_signal_instance_in_idle_cb (gdbusconnection.c:3701)
==31715== by 0x7AA7CF9: g_main_dispatch (gmain.c:3154)
==31715== by 0x7AA7CF9: g_main_context_dispatch (gmain.c:3769)
==31715== by 0x7AA8057: g_main_context_iterate.isra.29 (gmain.c:3840)
==31715== by 0x7AA8371: g_main_loop_run (gmain.c:4034)
==31715== by 0x5CEA204: gtk_main (gtkmain.c:1246)
==31715== by 0x403804: main (main.c:434)
Add "audio-device-selection-needed" which will be emitted when a
headphones, headset or microphone is plugged into a jack socket that
cannot detect which type it was.
Once the user of libgnome-volume-control has asked the user which type
of device this was, they can call gvc_mixer_control_set_headset_port()
to switch the ports for that configuration.
Note that gvc_mixer_control_set_headset_port() supports passing the
card ID, but the detection code only supports a single such device. When
we find hardware that can support > 1 such device, we can test and
implement support without breaking the API.
Based on the original code by David Henningsson <david.henningsson@canonical.com>
for the unity-settings-daemon
https://bugzilla.gnome.org/show_bug.cgi?id=755062
- Fix warning about comparison between signed and unsigned integer
expressions
- Change variable name 'output' to 'device' to fix warning:
declaration of 'output' shadows a parameter
- Fix warning about missing default case in switch
Entries are only hidden when available == PA_PORT_AVAILABLE_NO, so if an
entry toggles between PA_PORT_AVAILABLE_YES and
PA_PORT_AVAILABLE_UNKNOWN (Bluetooth headset switching between HSP/HFP
and A2DP for example), this should not result in new entries being created.
https://bugzilla.gnome.org/show_bug.cgi?id=697545
The "uint" type is not defined for standard C, and building with
-std=c99 enable stricter conformance and results in compilation failing.
Use "guint" instead.
This will allow to have different icons for internal audio cards
(which are flagged generically as "audio-card"), depending on which
port is in use (ie. headphones or speakers).
This requires the new icon information, which is only exported by
PulseAudio 3.0. If it's not available, we fallback to card icons
like before.
https://bugzilla.gnome.org/show_bug.cgi?id=689931
