[pulseaudio-discuss] Mixer connection when switching users

[Tanu Kaskinen]

On Mon, 2015-09-28 at 15:00 +0200, David Henningsson wrote:
> 
> 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.

Good!

> 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.

Yes, doing that was my plan.

Arun suggested unloading the whole card, though. That would be simpler.
I'm not sure if that will work, but I decided to try. Improving the
handling of default-routed streams is related to that - I don't think
we currently restore default-routed streams well enough when the card
appears again.

Another thing is that if we unload the card instead of suspending the
devices, streams will continue playing to some other sink (possibly
auto-null). Previously streams just stopped. I'm not sure if that's a
good or bad change.

-- 
Tanu