alsa device drain power

alsa device drain power

[Michael Trimarchi]

Hi all,

I have a simple question is the general behavior that an alsa device 
start to drain power
when it starts to play sound or start to recording. What happen if there 
is an external amplifier
connect to sound device?

Michael

Re: alsa device drain power

[Mark Brown]

On Thu, Dec 17, 2009 at 09:47:59AM +0100, Michael Trimarchi wrote:

> I have a simple question is the general behavior that an alsa device 
> start to drain power
> when it starts to play sound or start to recording. What happen if there 
> is an external amplifier
> connect to sound device?

In general any audio component is going to draw more power if there is a
signal going through it than if it's idle.  This is true regardless of
how the audio subsystem is split in terms of physical chips.

What are you trying to find out here?

Re: alsa device drain power

[Michael Trimarchi]

Mark Brown wrote:
> On Thu, Dec 17, 2009 at 09:47:59AM +0100, Michael Trimarchi wrote:
>
>   
>> I have a simple question is the general behavior that an alsa device 
>> start to drain power
>> when it starts to play sound or start to recording. What happen if there 
>> is an external amplifier
>> connect to sound device?
>>     
>
> In general any audio component is going to draw more power if there is a
> signal going through it than if it's idle.  This is true regardless of
> how the audio subsystem is split in terms of physical chips.
>
> What are you trying to find out here?
>
>   
As reported by the datasheet the LM4853 has a bias circuitry shutdown.
This shutdown function is activated by applying a logic high to the
SHUTDOWN pin. This pin as command by the

static int lm4853_event(struct snd_soc_dapm_widget *w,
                        struct snd_kcontrol *k,
                        int event)

in gta02. I don't put any debug stuff there but I suppose
if I open the device with and asound.conf that set
the value to true of the Stereo Out this event is called. Is it right?

Michael

Re: alsa device drain power

[Mark Brown]

On Fri, Dec 18, 2009 at 11:03:27AM +0100, Michael Trimarchi wrote:

> As reported by the datasheet the LM4853 has a bias circuitry shutdown.
> This shutdown function is activated by applying a logic high to the
> SHUTDOWN pin. This pin as command by the

So this is an ASoC-specific question, not a generic ALSA one...

> static int lm4853_event(struct snd_soc_dapm_widget *w,
>                         struct snd_kcontrol *k,
>                         int event)

> in gta02. I don't put any debug stuff there but I suppose
> if I open the device with and asound.conf that set
> the value to true of the Stereo Out this event is called. Is it right?

ASoC will only power things up if they're being used so setting that
control may or may not power things up.  I'm still not sure what you're
getting at with these questions - are you experiencing some problem, or
is this just a case of getting things straight in your head?

Re: alsa device drain power

[Michael Trimarchi]

Hi,

Mark Brown wrote:
> On Fri, Dec 18, 2009 at 11:03:27AM +0100, Michael Trimarchi wrote:
>
>   
>> As reported by the datasheet the LM4853 has a bias circuitry shutdown.
>> This shutdown function is activated by applying a logic high to the
>> SHUTDOWN pin. This pin as command by the
>>     
>
> So this is an ASoC-specific question, not a generic ALSA one...
>
>   
no, there are others embedded devices but I can test only on gta02
>> static int lm4853_event(struct snd_soc_dapm_widget *w,
>>                         struct snd_kcontrol *k,
>>                         int event)
>>     
>
>   
>> in gta02. I don't put any debug stuff there but I suppose
>> if I open the device with and asound.conf that set
>> the value to true of the Stereo Out this event is called. Is it right?
>>     
>
> ASoC will only power things up if they're being used so setting that
> control may or may not power things up.  I'm still not sure what you're
> getting at with these questions - are you experiencing some problem, or
> is this just a case of getting things straight in your head?
>
>   
Ok this is the stack dump

<6>Power up lm4853 <6>ON
<4>[<c0032948>] (dump_stack+0x0/0x14) from [<c02b40d8>] 
(lm4853_event+0x58/0x70)
<4>[<c02b4080>] (lm4853_event+0x0/0x70) from [<c02b09f4>] 
(dapm_power_widgets+0x360/0x3d8)
<4> r4:c697b960
<4>[<c02b0694>] (dapm_power_widgets+0x0/0x3d8) from [<c02b0b64>] 
(snd_soc_dapm_stream_event+0xf8/0x100)
<4>[<c02b0a6c>] (snd_soc_dapm_stream_event+0x0/0x100) from [<c02ae118>] 
(soc_pcm_prepare+0x17c/0x1e0)
<4> r8:c6987a08 r7:c0481464 r6:c04807f8 r5:c69bed60 r4:00000000
<4>[<c02adf9c>] (soc_pcm_prepare+0x0/0x1e0) from [<c02a1f88>] 
(snd_pcm_do_prepare+0x20/0x40)
<4>[<c02a1f68>] (snd_pcm_do_prepare+0x0/0x40) from [<c02a1b0c>] 
(snd_pcm_action_single+0x40/0x7c)
<4> r4:c048034c
<4>[<c02a1acc>] (snd_pcm_action_single+0x0/0x7c) from [<c02a4110>] 
(snd_pcm_action_nonatomic+0x5c/0x74)
<4> r7:c69873cc r6:c048034c r5:00020002 r4:c69bed60
<4>[<c02a40b4>] (snd_pcm_action_nonatomic+0x0/0x74) from [<c02a417c>] 
(snd_pcm_prepare+0x54/0x6c)
<4> r6:00020002 r5:00000000 r4:c69bed60
<4>[<c02a4128>] (snd_pcm_prepare+0x0/0x6c) from [<c02a6c50>] 
(snd_pcm_common_ioctl1+0x1f0/0x354)
<4> r7:c69bed60 r6:00004140 r5:00079f18 r4:00000000
<4>[<c02a6a60>] (snd_pcm_common_ioctl1+0x0/0x354) from [<c02a73c4>] 
(snd_pcm_playback_ioctl1+0x2c8/0x2fc)
<4> r5:00079f18 r4:00000000
<4>[<c02a70fc>] (snd_pcm_playback_ioctl1+0x0/0x2fc) from [<c02a74e0>] 
(snd_pcm_playback_ioctl+0x34/0x40)
<4> r7:00000036 r6:00004140 r5:00079f18 r4:c6bd58a0
<4>[<c02a74ac>] (snd_pcm_playback_ioctl+0x0/0x40) from [<c00b2d54>] 
(vfs_ioctl+0x3c/0x9c)
<4>[<c00b2d18>] (vfs_ioctl+0x0/0x9c) from [<c00b3418>] 
(do_vfs_ioctl+0x184/0x1ac)
<4> r6:c6bd58a0 r5:00079f18 r4:0000000b
<4>[<c00b3294>] (do_vfs_ioctl+0x0/0x1ac) from [<c00b3480>] 
(sys_ioctl+0x40/0x60)
<4> r6:00004140 r5:fffffff7 r4:c6bd58a0
<4>[<c00b3440>] (sys_ioctl+0x0/0x60) from [<c002de20>] 
(ret_fast_syscall+0x0/0x2c)
<4> r6:00060304 r5:ab79ddc4 r4:00079ed8

I don't send any sound to the device so it remains on, it's the correct 
behavior?

I will try to explain better:

android start and open playback device, and the system has the lm on, so 
it drains more power
that it needs. Of course when you do some call, it change again the 
status to OFF but return
to ON again

Michael



Michael

Re: alsa device drain power

[Mark Brown]

On Fri, Dec 18, 2009 at 01:20:51PM +0100, Michael Trimarchi wrote:

> I don't send any sound to the device so it remains on, it's the
> correct behavior?

What do you mean by that - what exactly is "send any sound to the
device" in this context?  Do you mean that you aren't playing any audio
from the CPU?  If so note that the WM8753 in the OpenMoko phones
supports various bypass paths which allow audio to be passed through the
device with no intervention from the CPU.

> android start and open playback device, and the system has the lm
> on, so it drains more power
> that it needs. Of course when you do some call, it change again the
> status to OFF but return
> to ON again

This sounds like the driver is performing as expected but you've s

DAPM will explain its power decisions in the debugfs under the ASoC
directory.

Re: alsa device drain power

[Michael Trimarchi]

Hi,

Mark Brown wrote:
> On Fri, Dec 18, 2009 at 01:20:51PM +0100, Michael Trimarchi wrote:
>
>   
>> I don't send any sound to the device so it remains on, it's the
>> correct behavior?
>>     
>
> What do you mean by that - what exactly is "send any sound to the
> device" in this context?  Do you mean that you aren't playing any audio
> from the CPU?  
I don't play any audio file (mp3 ogg) to the device but open it during 
boot sequence
using the SpeakerOut profile. The speake audio path is not used.
For design decision Android open the device in
AudioFlinger Theread:

I/AudioHardwareALSA(  867): Initialized ALSA PLAYBACK device 
AndroidPlayback_Speaker_normal
D/AudioHardwareALSA(  867): Set PLAYBACK PCM format to S16_LE (Signed 16 
bit Little Endian)
D/AudioHardwareALSA(  867): Using 2 channels for PLAYBACK.
D/AudioHardwareALSA(  867): Set PLAYBACK sample rate to 44100 HZ
D/AudioHardwareALSA(  867): Buffer size: 16384
D/AudioHardwareALSA(  867): Latency: 371519

and this remains open. So the the lm is switch on on boot. I think that 
the correct behavior
is to have a different profile in asound.conf to avoid power drain and 
open a different one when
the system want to use the speaker or just not open the alsa device.

Hope that the now is clear

Best regards
Michael