[alsa-devel] alsa device drain power
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
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?
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
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?
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
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.
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
participants (2)
-
Mark Brown -
Michael Trimarchi