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

[Colin Guthrie]

'Twas brillig, and Daniel Chen at 15/01/10 16:24 did gyre and gimble:
> 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?

Well pacmd isn't really a regular PA client.... it connects via a
different IPC mechanism. It would be better to use pactl here I believe.

Regardless I'm not too sure what is happening here that would be
different to before. Perhaps the fix for #771 (not accessing the mixer
when not the active user) is at fault here.

You seem to try and run pacmd for all users, but really only the PA
processes from the active seats (found via consolekit) really needs to
do this as all other users wont have access the h/w anyway.

Thinking about the fix (which is very simple), I suspect it's not really
what's at fault... so in short, I dunno :p

> (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.)
> 
> Any assistance debugging the symptoms is much appreciated.

Well (to me) the correct approach would be a fairly simple module inside
PA itself that listened for suspend and resume notifications (I don't
know this area but I presume something goes out via dbus to let apps
know about this??) that does a quick volume ramp down -> volume ramp up
for all devices (I only say volume ramp as it would be a nice effect :D)

While the volume ramping code is pretty new and git master only (AFAIK),
the basic "track state, mute all, <suspend> <resume>,
un-mute-those-which-were-unmuted-before-suspend" functionality should be
achievable with not too much effort (assuming said dbus signal for
suspend/resume exists - although I guess a simple pm-utils script to
send such signals would be pretty trivial anyway if it doesn't).

Probably wouldn't take too long to knock up and it keeps things nicely
inside PA itself rather than scattered around the system.

Just an idea.... :)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]