On Thu, Nov 19, 2009 at 12:57 PM, Julian Lam <email address hidden> wrote:
> So this is a hardware-specific issue? If that's the case, then in the
> interest of usability, shouldn't we keep the old behaviour and wait for
> hardware to comply with software?
No, the all unmuted behavior is caused by 01PulseAudio, the pm-utils
script. What is hardware specific is the popping upon suspend and/or
resume.
> On second thought - wouldn't it be easier if the current state of PA
> (muted/unmuted) was saved to RAM before sleep, and restored upon
> restoration?
We do save this state already directly in the ALSA driver, because PA
syncs its volumes with that reported to/by the driver. The problem is
that you need to mute the sink & sources prior to suspend, which
causes the ALSA driver to store muted state. Notice how there isn't an
ability to store prior state, because that's what's needed: you need
to save the state prior to the muted state so that the pop isn't
audible.
On Thu, Nov 19, 2009 at 12:57 PM, Julian Lam <email address hidden> wrote:
> So this is a hardware-specific issue? If that's the case, then in the
> interest of usability, shouldn't we keep the old behaviour and wait for
> hardware to comply with software?
No, the all unmuted behavior is caused by 01PulseAudio, the pm-utils
script. What is hardware specific is the popping upon suspend and/or
resume.
> On second thought - wouldn't it be easier if the current state of PA
> (muted/unmuted) was saved to RAM before sleep, and restored upon
> restoration?
We do save this state already directly in the ALSA driver, because PA
syncs its volumes with that reported to/by the driver. The problem is
that you need to mute the sink & sources prior to suspend, which
causes the ALSA driver to store muted state. Notice how there isn't an
ability to store prior state, because that's what's needed: you need
to save the state prior to the muted state so that the pop isn't
audible.