[PATCH powerd] Inhibit suspend while audio device is open

[Paul Fox]

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 <silbe at 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, pgf at laptop.org