This is a rebase of !307, minus the refactoring patches. Works mostly fine on my chromebook (tested with other fixes), except the devices are also "muted" when suspended. If I shutdown PulseAudio when devices are muted like this, the muted state is restored at startup and I have to manually unmute them to use them.
As far as I can tell the root cause is
DisableSequence commands using the controls also listed in
PlaybackMixerElem etc. I think it fits the mute issue reported on the original MR. I'm especially suspicious of this UCM fragment with mismatched enable-disable sequences, or something like that. Here's how it might be happening:
- PA reads
Speaker Playback Switchas hardware mute
- PA decides to suspend device, calls alsa-lib to disable it
- alsa-lib runs
DisableSequence, turns off
Speaker Playback Switch
- PA notices
Speaker Playback Switchis now off, marks device as muted (shows up in UIs)
- User starts audio playback
- PA decides to wake device, calls alsa-lib to enable it
- alsa-lib runs
EnableSequence, does nothing because it's empty
- PA didn't mute the device, so has no reason to un-mute it itself
- User notices device is still muted, has to manually un-mute to get audio
In my chromebook's config,
EnableSequence does turn on whatever
DisableSequence turns off, so it works fine. Still, stopping PulseAudio in the middle results in device volume being saved as "muted". I'd even say it shouldn't show up as muted in any point of this.
Although I definitely think UCM configs are at fault here, I don't think we can just say "Go fix your UCM config" to everyone, and don't know how else we can solve it. So marking this MR as a draft. Anyone wanting to test this should make sure to also have the hardware volume fixes, otherwise things will merely appear to work because your devices are silently downgraded to software volume control.