[pulseaudio-discuss] [PATCH] Run a user specified program on suspend/resume.

Tanu Kaskinen tanuk at iki.fi
Tue Dec 8 05:26:30 PST 2015


On Mon, 2015-12-07 at 18:19 +0200, Tanu Kaskinen wrote:
> On Fri, 2015-08-21 at 23:29 +0300, Joonas Govenius wrote:
> > This allows calling a user-specified external program whenever a
> > source or sink is suspended or resumed (by specifying
> > external_suspend_handler="" as an option to
> > module-suspend-on-idle). The external executable is called
> > with "--suspended" or "--resumed" followed by "--source
> > " or "--sink ".
> > 
> > My use case for this feature is to cut the power to my active
> > speakers in order to eliminate hissing. I've been using the patch
> > (applied to pulseaudio 4.0) on Ubuntu 14.04 since February. I
> > have not tested it with later versions, except to check that it
> > compiles. I could do some further testing if the patch is
> > otherwise acceptable/useful enough.
> > 
> > Some things I'm not sure about:
> > 
> > * What happens on Windows? Does fork() work and if not, what does
> >   it return? Maybe some of the code should be wrapped
> >   with "#ifndef OS_IS_WIN32".
> > 
> > * Security considerations? This might provide a sneaky way to run
> >   malicious code repeatedly, but only if you have write access to
> >   the config file. In that case you are probably screwed in a
> >   multitude of ways already...
> 
> Write access to the file system is not needed. The only thing that is
> needed is access to PulseAudio, because you can load modules also at
> runtime. Using the module arguments to pass the executable doesn't seem
> safe enough. Maybe we could add suspend-on-idle.conf, and have that the
> only way to specify the external_suspend_handler option?

By the way, why does this functionality need to be in the daemon?
Clients can monitor the device state, so why not trigger the script
from client side?

-- 
Tanu


More information about the pulseaudio-discuss mailing list