[pulseaudio-discuss] Unsynchronised ALSA and PA volumes with fast user switching

[Tanu Kaskinen]

On Fri, 2012-03-30 at 17:22 +0200, David Henningsson wrote:
> Steps to reproduce:
> Log in as user A.
> Fast user switch to user B.
> Let user B change port / volume / mute.
> Fast user switch back to user A.
> 
> At this point ALSA and PA volumes are unsynchronised, ALSA is still at 
> B's volume, whereas PA thinks it has A's volume.
> 
> I'm trying to make PA set ALSA to A's volume when A comes back, but the 
> best I can come up with is an ugly hack: to
> 1) read the old volume

What does this mean? What code is reading what volume?

> 2) call set_port
> 3) read the volume again and discard the result (!)
> 4) set the old volume
> 
> It seems difficult just to "invalidate" the remembered ALSA 
> port/volume/mute and set it again, but I might very well be missing 
> something (all these volumes are a bit mind-boggling).
> 
> Ideas welcome.

Disclaimer: I'm answering quickly without looking at the code, and I
don't know why you need the juggling with the volume. I'm trying to
think what "should" be happen.

When switching to B, A should notice that and tear down the current
port. I think that mainly means releasing the device, and I guess this
part is working fine. When A gets active again, the port should be
reactivated. Therefore, the "call set_port" step of your ugly hack is
not a hack, it's what should be done. As part of initializing the port,
volume and mute should be set. What's the problem here? Does the port
setting code assume that if the pa_sink.reference_volume hasn't changed,
the hardware volume doesn't need to be set? If so, then that assumption
needs to be removed. When activating a port, the hardware volume should
always be set (or alternatively the current volume should be read from
the hardware, and then set if needed).

-- 
Tanu