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
