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

Zarro Boogs per Child bugtracker at laptop.org
Wed May 12 12:08:12 EDT 2010


#10160: expose the audio codec's "in use" state to user level
-------------------------+--------------------------------------------------
 Reporter:  pgf          |                 Owner:  dsaxena                           
     Type:  enhancement  |                Status:  new                               
 Priority:  normal       |             Milestone:  1.5-software-update               
Component:  kernel       |               Version:  Development source as of this date
 Keywords:               |           Next_action:  design                            
 Verified:  0            |   Deployment_affected:                                    
Blockedby:               |              Blocking:                                    
-------------------------+--------------------------------------------------
 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)
 }}}

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


More information about the Bugs mailing list