[pulseaudio-discuss] RFC: Saving volumes when suspended
gmane at colin.guthr.ie
Tue Jan 5 06:32:28 PST 2010
'Twas brillig, and Lennart Poettering at 05/01/10 13:55 did gyre and gimble:
> On Tue, 05.01.10 11:18, Colin Guthrie (gmane at colin.guthr.ie) wrote:
>> It seems that there is conflict between GDM and real user accounts which
>> is affecting volume saving.
>> The short description of the problem is that after logout, your user's
>> PA remains until the exit timeout but still processes volume saves. As
>> you logout, GDM is spawned and restores the volume to the value it has
>> in it's m-d-r database, your PA notices this "change from ALSA" and
>> saves it thus overwriting the real volume you left it with.
>> More detailed info here:
> Ah, good catch! Thanks for figuring that one out. I was puzzled by
> this one.
Yeah, as you can tell from the comment on the ticket above I actually
only worked out the problem at the end of my analysis - the bit where I
asked you "if it was harmless" is the whole problem :p
>> So, what to do about this?
>> I propose that while consolekit says our user is inactive we ignore any
>> volume changes that come in via alsa. When our user becomes active, we
>> restore the device volumes.
> Hmm, for that to not be racy we'd have to *synchronously* check the
> ckit status on every alsa mixer change. That could be very slow. OTOH,
> if we did it asynchronously we'd just shift around the race...
> Hmm, what about this: do an access() on the control device
> (i.e. /dev/snd/controlC0) after each volume change and ignore the
> volume change if the device is not accessible to us? Since the ACL
> change should happen synchronously before the other side gets access
> this should fix the issue, shouldn't it?
That will fix half the problem yes, but we need to watch for our session
becoming active and apply our saved volumes again too.
1) Login as user A set volume to 20%
2) Login as user B set volume to 50% (user A's PA ignores change due to
access() failure - good!).
3) Switch back to user A, volume is still at 50% but this user wants it
at 20% :s
This part should be simple I think - just need to make sure it's not
> That sounds like a workable solution do me, do you agree? Also is much
> easier to implement, which is nice, too...
I think it sounds sensible yes.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss