codec power question

codec power question

[Koul, Vinod]

Hi,

In some cases the audio stream is kept ON and idle by application. In
that case codec is also ON. Is there a mechanism where DAPM can detect
this idle condition and turn off the idle widgets or turn of the codec
BIAS

-- 
~Vinod

Re: codec power question

[Koul, Vinod]

On Tue, 2011-03-15 at 15:10 +0530, Koul, Vinod wrote:
> Hi,
> 
> In some cases the audio stream is kept ON and idle by application. In
> that case codec is also ON. Is there a mechanism where DAPM can detect
> this idle condition and turn off the idle widgets or turn of the codec
> BIAS
> 
Oops messed up Marks email, fixed now...

-- 
~Vinod

Re: codec power question

[Mark Brown]

On Tue, Mar 15, 2011 at 03:10:23PM +0530, Koul, Vinod wrote:

> In some cases the audio stream is kept ON and idle by application. In
> that case codec is also ON. Is there a mechanism where DAPM can detect
> this idle condition and turn off the idle widgets or turn of the codec
> BIAS

If this is happening it's a framework bug - if there are no active audio
streams through the device then it should be brought down to the lowest
power state.  The application doesn't have any direct control over the
CODEC power except by configuring audio streams.  Can you provide any
more details on how this happens?

Note that for playback streams there's a delay before things are powered
down to avoid delays, pops and clicks when doing things like changing
tracks.  By default the delay is 5s.

Re: codec power question

[Koul, Vinod]

On Tue, 2011-03-15 at 17:00 +0530, Mark Brown wrote:
> On Tue, Mar 15, 2011 at 03:10:23PM +0530, Koul, Vinod wrote:
> 
> > In some cases the audio stream is kept ON and idle by application. In
> > that case codec is also ON. Is there a mechanism where DAPM can detect
> > this idle condition and turn off the idle widgets or turn of the codec
> > BIAS
> 
> If this is happening it's a framework bug - if there are no active audio
> streams through the device then it should be brought down to the lowest
> power state.  The application doesn't have any direct control over the
> CODEC power except by configuring audio streams.  Can you provide any
> more details on how this happens?
In andriod, flinger opens the streams at boot and keeps them ON, and
doesn't close the stream when in idle.
Since the stream in ON, codec consumes lot of power, I was wondering if
we have something in asoc to detect this kind of state and do much
better power control.

-- 
~Vinod

Re: codec power question

[Mark Brown]

On Tue, Mar 15, 2011 at 05:57:27PM +0530, Koul, Vinod wrote:

> In andriod, flinger opens the streams at boot and keeps them ON, and
> doesn't close the stream when in idle.
> Since the stream in ON, codec consumes lot of power, I was wondering if
> we have something in asoc to detect this kind of state and do much
> better power control.

Ah, this is just a plain userspace bug in the default ALSA thing that
went up on the Android git - there's no way sensible way to figure out
that userspace is playing silence because it's being silly.

The Nexus S libaudio does a better job here though it has its own issues
due to the integration with the non-mainline CODEC driver they're using.