sascha wrote: > 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 <si...@activitycentral.com> > --- > 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 > +}
i've played with this a bit more, including taking a further look at the driver. 1) i think we should expand the expression to: egrep -q 'RUNNING|DRAINING' /proc/asound/card0/pcm0?/sub0/status 2) i tried the inotifywait trick mentioned in #6670. inotify picks up open and close events on the device, which could aid in knowing when the device was used, but it doesn't pick up on the data writes because they're often done with ioctl(SNDRV_PCM_IOCTL_WRITEI_FRAMES,...) instead of write(). so i don't think that's useful. 3) as far as the activity testing you did, i agree with your results -- i didn't try everything, but Scratch is certainly the biggest violator, in that it keeps the device in RUNNING state even when not playing anything, and when not in the foreground. observed with strace, Scratch actually continuously writes (using ioctl()) to the device. perhaps someone could work with the scratch authors on this? the browsers do seem to let the device out of RUNNING state, though as you noted they do still prevent others from using the audio device (a separate problem). the TamTam family isn't great either. this is all just further data. i'm really not in a position to say what the goal should be for powerd and audio for 12.1 or 12.2. paul > > > # 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 =--------------------- paul fox, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel