On 2015-09-18 18:07, Tanu Kaskinen wrote:
Hi,
I noticed that my headphone volume wasn't getting restored properly
when plugging in the headphones. The probable cause turned out to be
that gdm's PulseAudio instance was messing with the mixer controls,
causing mixer update events in my own PulseAudio instance.
At the time I logged in, the gdm user lost access to the sound cards,
but Linux doesn't revoke access to file descriptors that are already
open. PulseAudio voluntarily closes the PCM device connections in that
situation, but PulseAudio doesn't close the mixer connection, so gdm
still had access to the mixer, and the jack detection events caused the
gdm to fiddle with the mixer controls.
I will fix this issue, but I'm not sure how I should do that. There
might be some simple fix that would prevent mixer modifications when
the sink suspend cause is PA_SUSPEND_SESSION, but I could also do a
bigger change: close the mixer connection when udev changes the device
permissions. I think it's a bug in itself that we keep the mixer
connection open, even if in practice there's no harm from doing that.
Do others think the same, or should I try to only make a minimal fix,
adding a check somewhere that prevents writes to the mixer when
PA_SUSPEND_SESSION is set?
Sorry for the late answer.
I tend to agree, we should close the mixer connection if we don't have
any access rights to it anyway.
The fun thing happens when we have access again though - I think we
first need to re-check jack detection stuff and update our current port
(via module-switch-on-port-available), then we should probably
synchronize volumes regardless of whether the port changed or not? And
by that I mean always pushing our volume to the device, not the other
way around.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
