Audio playback and recording can be efficient enough not to trigger the CPU threshold, but we still don't want to suspend because it would interrupt the playback resp. recording.
While there's a number of Activities (and probably Gnome applications as well) that don't close the audio device when they're done using audio, thus inhibiting suspend for longer than necessary, that's a problem on its own as it will also prevent other Activities from using the audio device. There are many other ways of Activities misbehaving and consuming a lot of resources. The increased battery drain by inhibiting suspend is easy enough for users to observe by watching the power LED. Signed-off-by: Sascha Silbe <[email protected]> --- powerd | 14 ++++++-------- 1 files changed, 6 insertions(+), 8 deletions(-) diff --git a/powerd b/powerd index c6d9487..09f9153 100755 --- a/powerd +++ b/powerd @@ -1199,13 +1199,10 @@ cpu_or_network_busy() } -# unused for now, because too many sound apps leave the -# device open: the TamTams, Record (after playing), Browse -# and Firefox (after playing) -#audio_busy() -#{ -# grep -q RUNNING /proc/asound/card0/pcm0?/sub0/status && trace audio busy -#} +audio_busy() +{ + grep -q RUNNING /proc/asound/card0/pcm0?/sub0/status && trace audio busy +} # see if there's been activity during the recent idle period -- @@ -1330,7 +1327,8 @@ general_inhibit() laptop_busy() { - general_inhibit || usb_inhibit || ttyusb_inhibit || cpu_or_network_busy + general_inhibit || usb_inhibit || ttyusb_inhibit || cpu_or_network_busy \ + || audio_busy } if [ -e $TPAD_RECAL ] -- 1.7.9 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
