[pulseaudio-tickets] [PulseAudio] #572: PulseAudio mutes Master channel upon logout

[PulseAudio]

#572: PulseAudio mutes Master channel upon logout
----------------------------+-----------------------------------------------
  Reporter:  diverse_izzue  |       Owner:  lennart
      Type:  defect         |      Status:  new    
 Milestone:                 |   Component:  daemon 
Resolution:                 |    Keywords:         
----------------------------+-----------------------------------------------

Comment(by coling):

 Sorry for not replying sooner :(

 So
  * PA PID 1502 is from the GDM login.
  * PA PID 1639 is one for you that is started after you login from GDM
  * PA PID 1636 is the result of a {{{pulseaudio --start}}} presumably as
 part of start-pulseaudio-x11. It is only used to launch PA itself, so
 isn't interfering.
  * PA PID 1680 is interesting. I'm not sure where that one came from. It
 seems to be the result of running {{{pulseaudio}}} e.g. without the
 --start argument. Not sure what triggered that but again it doesn't seem
 to be getting in the way - it's error is not logged for some reason but I
 presume it's actually given the following error is generated here:
 {{{
 I: main.c: Running in system mode: no
 E: pid.c: Daemon already running.
 E: main.c: pa_pid_file_create() failed.
 }}}
  * PA PID 1672 seems to be the result of a {{{pulseaudio --start}}} as per
 1636. (a minor curiosity here is if 1672 actually launched 1680 (it seems
 1636 launched 1639). This could be the expected behaviour tho).

 Interestingly GDMs PA continues to save the volumes even though it's not
 active - see lines 504 and 513 (e.g. your users PA (1639) makde changes
 via ALSA and are detected by GDMs PA (1502) and thus saved)... I wonder if
 this should be done? Lennart, your thoughts on this, if we are suspended
 should we ignore this or is this harmless?

 Anyway at this point all that has happened is that you've started your
 user session (PID 1639). At this point the GDM pa dies off (due to its
 session being no longer valid and the idle time being reached. When this
 happens your user session continues but we've not yet seen any instance of
 it having volumes set (e.g. manually after you've logged in) nor what
 happens when it dies off after you logout (which is when I suspect the
 error value is written by some wayward alsa client). So more log is
 probably needed.

 In actual fact tho' I think I can see the problem here:

  1. GDM PA runs and has the volume set a level X.
  2. Your PA startups up and sets the volume to level Y during it's log in
 sequence.
  3. GDM's PA is still running and records your volume Y, so now X == Y.
  4. GDM's PA dies off naturally.
  5. Your PA sets the volume to level Z via your input (where Z is a
 sensible value).
  6. Your PA saves this value (so far so good).
  7. You logout. Your PA does not die (as expected and hangs around for a
 little while).
  8. GDM is started again to process the next login.
  9. GDM's new PA is started and restores the volume to X.
  10. Your PA is still running and notices this change from "alsa" and
 saves this volume.
  11. Your PA exists after idle timeout but not before the original value
 of X overwrites the nice value Z you set.

 Then the cycle continues.

 I suspect this is the problem. I will ask Lennart to comment on the
 solution here.

-- 
Ticket URL: <http://pulseaudio.org/ticket/572#comment:19>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server