[pulseaudio-discuss] Need assistance debugging symptom of pacmd spinning during suspend-to-ram attempt

[Lennart Poettering]

On Fri, 15.01.10 11:24, Daniel Chen (seven.steps at gmail.com) wrote:

> Hi,
> 
> For the latest stable-queue branch, at
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/507941
> there's a report of pacmd consuming 100% CPU when suspending-to-ram.
> It seems to be triggered by running the pm-utils script at
> http://bazaar.launchpad.net/~ubuntu-core-dev/pulseaudio/ubuntu/annotate/head%3A/debian/01PulseAudio
> . Is there something blatantly incorrect in the use(s) of pacmd in
> that script, or should we consider a pacmd regression?
> 
> (History of said pm-utils script: it's an attempt to mute all sinks
> and sources prior to suspending so that speakers/headphones don't pop.
> Upon resume the script attempts to restore the existing, i.e., prior
> to suspend, user sink and source state. While I realize that the
> popping on suspend is really a linux issue, and my patches to fix
> those for several HDA codecs have landed in upstream alsa-driver, the
> work is not complete.)

BTW, I'd prefer if you would work with the upower/gpm folks to add
some kind of API so that PA can be notified before we go into a
suspend. 

Synchronously changing to user priviliges to execute the pacmd script
is insecure business, since user code might actually block your script
indefinitely, which is kinda risky since some machines don't survive if
you close the lid but continue to run full power. Notification to user
software of suspends needs to happen asynchronously/be timeouted
globally. And the place to implement that is upower/gpm.

>From PA's point of view suspending the device before we go into sleep
mode is actually the right thing, not so much to work around driver
bugs, but simply because this would be very helpful for our timing
estimation, since a system sleep actually means a prolonged gap in the
wallclock time whre we aren't scheduled. It would clean if we could be
notified about that and suspend our timing interpolation temporarily.

So, I think the goal what you are trying to do is a good, but I am not
happy about the way you implemented it.

> Any assistance debugging the symptoms is much appreciated.

An strace would be good.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4