#10160 NORM 1.5-sof: expose the audio codec's "in use" state to user level

[Zarro Boogs per Child]

#10160: expose the audio codec's "in use" state to user level
-----------------------------------+----------------------------------------
           Reporter:  pgf          |       Owner:  cjb                               
               Type:  enhancement  |      Status:  assigned                          
           Priority:  normal       |   Milestone:  1.5-software-update               
          Component:  kernel       |     Version:  Development source as of this date
         Resolution:               |    Keywords:                                    
        Next_action:  design       |    Verified:  0                                 
Deployment_affected:               |   Blockedby:                                    
           Blocking:               |  
-----------------------------------+----------------------------------------
Changes (by cjb):

  * owner:  dsaxena => cjb
  * status:  new => assigned


Old description:

> for purposes of managing idle-suspend, it would be very convenient to
> know when the audio device is in use (as opposed to merely "open", status
> which is already available).
>
> it seems the kernel may already be tracking this, at least for the case
> of the output device:
> {{{
> <pgf> audio is actually an annoying case.  it turns out it's really easy
> to tell, from alsa state, whether the input or device is open.
> <pgf> unfortunately, all the audio apps open it when they start, and
> never close it, whether it's in use or not.
> <dsd_> the kernel tracks audio codec use and powers it down after 5 secs
> of inactivity
> <dsd_> and this works well, so presumably doesnt face the same problem
> <dsd_> i wonder if you can view that state somehow
> <cjb> dsd_: yeah, already tried that, doesn't seem to be exposed
> <cjb> but would be an easy patch to write, setting and exposing a flag
> through snd_pcm_playback and snd_pcm_capture.
> <cjb> pgf: if you want to file a bug with the interface you'd like, I
> could work on that
> <pgf> oh, that's a good idea.
> <pgf> i didn't realize the kernel was already doing that work.
> <pgf> so we think the codec is only powered when it's in use (or recently
> so)?
> <dsd_> yeah i think so
> <dsd_> but we should also check that its not affected by that same issue
> with open/close
> <pgf> right.
> <cjb> pgf: yes, see sound/pci/hda/hda_codec.c; when we stop sending
> samples, we queue up a power down for CONFIG_SND_HDA_POWER_SAVE_DEFAULT
> seconds.
> <cjb> (=5 for us)
> }}}

New description:

 for purposes of managing idle-suspend, it would be very convenient to know
 when the audio device is in use (as opposed to merely "open", status which
 is already available).

 it seems the kernel may already be tracking this, at least for the case of
 the output device:
 {{{
 <pgf> audio is actually an annoying case.  it turns out it's really easy
 to tell, from alsa state, whether the input or device is open.
 <pgf> unfortunately, all the audio apps open it when they start, and never
 close it, whether it's in use or not.
 <dsd_> the kernel tracks audio codec use and powers it down after 5 secs
 of inactivity
 <dsd_> and this works well, so presumably doesnt face the same problem
 <dsd_> i wonder if you can view that state somehow
 <cjb> dsd_: yeah, already tried that, doesn't seem to be exposed
 <cjb> but would be an easy patch to write, setting and exposing a flag
 through snd_pcm_playback and snd_pcm_capture.
 <cjb> pgf: if you want to file a bug with the interface you'd like, I
 could work on that
 <pgf> oh, that's a good idea.
 <pgf> i didn't realize the kernel was already doing that work.
 <pgf> so we think the codec is only powered when it's in use (or recently
 so)?
 <dsd_> yeah i think so
 <dsd_> but we should also check that its not affected by that same issue
 with open/close
 <pgf> right.
 <cjb> pgf: yes, see sound/pci/hda/hda_codec.c; when we stop sending
 samples, we queue up a power down for CONFIG_SND_HDA_POWER_SAVE_DEFAULT
 seconds.
 <cjb> (=5 for us)
 }}}

--

Comment:

 Do you have any more thoughts on what the interface should look like?

 I suppose we actually want "have any samples been sent in the last N
 seconds", perhaps with N equal to CONFIG_SND_HDA_POWER_SAVE_DEFAULT, so as
 to avoid getting a "device isn't in use" reading when samples are being
 sent, just not with the same period that we're asking about them.

 .. ah hah.  See #6670, looks like dilinger had a shot at this once, back
 on XO-1, but didn't finish.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10160#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system