Skip to content

Draft: mixer-control: mixer-ui-device: Bind device-availability to ability to switch profile

Jonas Dreßler requested to merge verdre/libgnome-volume-control:hide-unselectable-profiles into master

Opened this one as a bit of an RFC that could go on top of !26 (the MR currently includes those commits).

This hides the second, unselectable audio output device on Asahi laptops. The approach has a few drawbacks, but IMO it's technically more correct than the current code. If people have better ideas for fixing the problem, I'd be really happy to hear them!

Visibililty/availability of UIDevices to users is a bit tricky:

In general what is relevant from a PulseAudio perspective are only the streams, as those are the "objects" which application audio really gets routed into. The big complication with the PulseAudio APIs we're dealing with, is that those streams might appear only once we switch the card profile. This is the reason UIDevice "availability" exists and why we need to offer UIDevices to the user even if they don't actually have an associated stream.

Currently, we expose the following combination of ports and source/sink streams to the user:

  1. streams which are associated with a port that is not UNAVAILABLE, ie. stream && port && port != UNAVAILABLE. Due to having a stream, these UIDevices are valid sources/sinks for audio that we safely switch to.

  2. streams which are not associated with a port, ie. stream && !port. Also due to having a stream, these UIDevices are valid sources/sinks for audio that we can safely switch to.

  3. ports which are not UNAVAILABLE and not associated with a stream, ie. !stream && port && port != UNAVAILABLE. These UIDevices are the tricky ones: They don't have a stream, so we can't use them as a source/sink right away. We still show them thoguh because we hope that a stream for this port will appears once we switch the card to one of the port-profiles.

Now for case 3), we can narrow availability/visibility down a little more actually: We offer these UIDevices as a switching-target to the user, because we assume the card profile can be switched and then a stream will appear. But we could do more to check for that: The card profile might already be set to a port-profile, but there's still no stream available. In this case, we can safely assume the UIDevice is impossible to stream audio from/to, and hide it.

On Asahi laptops (where all audio goes into a virtual sink that is an equalizer), this hides the "real speaker" port, which can't ever be used (because it doesn't have a stream).

Note that this solution has a few downsides too:

  • If a port doesn't have its profile selected on the card, we would show that port. But when the user switches to it and now no stream appears, the port would go away and remain hidden. Technically, this is the correct behavior, as clearly that port can't be usedm it might be unexpected that the UIDevice goes away though.

  • During profile switching with a Bluetooth headset, for a short timespan, the profile is already switched, but no stream has appeared yet. This means that for a short time, the UIDevice will be unavailable and therefore disappear for our clients.

Merge request reports