[alsa-devel] Triggering a DAPM widget event
Hi all,
I have a program that uses the ALSA PCM interface to play sounds on an embedded system. Does anyone know how alsa-lib triggers a SND_SOC_DAPM_PRE_PMD widget event in DAPM core? On my system the event only gets called when the pcm is closed with snd_pcm_close(). Is there another function that can cause a widget shutdown?
Or is opening and closing the PCM every time I want to play a sound a good practice for saving power?
Regards,
John
________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
On Tue, Jan 25, 2011 at 05:53:13PM +0100, Harrod, John wrote:
Please CC maintianers on mails, things on mailing lists get lost easily. Please also fix your MUA to word wrap within paragraphs, I've reflowed your mail below so I can read it.
I have a program that uses the ALSA PCM interface to play sounds on an embedded system. Does anyone know how alsa-lib triggers a SND_SOC_DAPM_PRE_PMD widget event in DAPM core? On my system the event only gets called when the pcm is closed with snd_pcm_close(). Is there another function that can cause a widget shutdown?
A pre-powerdown even is generated before a DAPM widget is powered down. This will happen whenever it ceases to be part of an active audio path. This is not something that is visible at application layer.
Or is opening and closing the PCM every time I want to play a sound a good practice for saving power?
You should never need to close application layer streams. You should stop data flowing on them when you are not transferring audio since obviously even ignoring the CODEC power sitting DMAing data when you're not playing audio is going to waste power.
I ran a few experiments where I frequently opened and closed the PCM. Under a heavy load, I sometimes get a resource busy error when I use the snd_pcm_open() call. So it looks like alsa-lib is not designed for frequent pcm opening and closing. I also noticed a few points in the alsa-lib code where dynamic memory is being allocated and freed and am wondering how this would affect heap fragmentation in the long term.
So the pre-powerdown event should occur when no sound is being played? When you say stop the data flowing, you mean within the sound kernel module? There is no call that I need to make to alsa-lib (for example making a call to snd_pcm_pause())? It sounds like something is not working correctly in the kernel module...
-----Original Message----- From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com] Sent: Wednesday, January 26, 2011 11:54 AM To: Harrod, John Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Triggering a DAPM widget event
On Tue, Jan 25, 2011 at 05:53:13PM +0100, Harrod, John wrote:
Please CC maintianers on mails, things on mailing lists get lost easily. Please also fix your MUA to word wrap within paragraphs, I've reflowed your mail below so I can read it.
I have a program that uses the ALSA PCM interface to play sounds on an embedded system. Does anyone know how alsa-lib triggers a SND_SOC_DAPM_PRE_PMD widget event in DAPM core? On my system the event only gets called when the pcm is closed with snd_pcm_close(). Is there another function that can cause a widget shutdown?
A pre-powerdown even is generated before a DAPM widget is powered down. This will happen whenever it ceases to be part of an active audio path. This is not something that is visible at application layer.
Or is opening and closing the PCM every time I want to play a sound a good practice for saving power?
You should never need to close application layer streams. You should stop data flowing on them when you are not transferring audio since obviously even ignoring the CODEC power sitting DMAing data when you're not playing audio is going to waste power.
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
On Wed, Jan 26, 2011 at 07:08:31PM +0100, Harrod, John wrote:
http://daringfireball.net/2007/07/on_top
I ran a few experiments where I frequently opened and closed the PCM. Under a heavy load, I sometimes get a resource busy error when I use the snd_pcm_open() call. So it looks like alsa-lib is not designed for frequent
Two issues here: - Opening and closing streams are not the same thing as stopping and starting them. From a power point of view only the stoping and starting of data transfer should make any difference.
- That said should be no problem with opening and closing streams as often as you like. It seems most likely that if there's an issue here it's due to a race condition somewhere or other, quite possibly in the driver code.
pcm opening and closing. I also noticed a few points in the alsa-lib code where dynamic memory is being allocated and freed and am wondering how this would affect heap fragmentation in the long term.
Obviously any dynamic memory allocator will be designed to deal with frequent allocations and frees. I would be astonished if this caused a serious issue.
So the pre-powerdown event should occur when no sound is being played? When you say stop the data flowing, you mean within the sound kernel module? There is no call that I need to make to alsa-lib (for example making a call to snd_pcm_pause())? It sounds like something is not working correctly in the kernel module...
Just stop playing data from your application. For PCM streams from the CPU that's all your application should need to do.
What is your actual problem here?
What is your actual problem here?
I have a speaker widget (snd_soc_dapm_spk) whose event handler only receives a SND_SOC_DAPM_PRE_PMD event when the pcm is closed.
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
On Wed, Jan 26, 2011 at 09:38:53PM +0100, Harrod, John wrote:
As previously mentioned please fix your mail client to word wrap mails within paragraphs so that they are legible.
What is your actual problem here?
I have a speaker widget (snd_soc_dapm_spk) whose event handler only receives a SND_SOC_DAPM_PRE_PMD event when the pcm is closed.
Why is this a problem? As I said in my previous e-mail if you don't stop playing audio the kernel will of course keep power up on the output path from the DAC.
On 01/26/11 22:38, ext Harrod, John wrote:
What is your actual problem here?
I have a speaker widget (snd_soc_dapm_spk) whose event handler only receives a SND_SOC_DAPM_PRE_PMD event when the pcm is closed.
Events on widgets are (among others): SND_SOC_DAPM_PRE_PMU: will be sent before the widget power up SND_SOC_DAPM_POST_PMU: will be sent after the widget power up SND_SOC_DAPM_PRE_PMD: will be sent before the widget power down SND_SOC_DAPM_POST_PMD: will be sent after the widget power down
The *_PMU events are triggered whenever the widget is going to be powered up: stream start, within prepare time; complete bypass, or loopback path
The *_PMD events are triggered whenever the widget is going to be powered down: bypass, or loopback path is disabled After the stream has been stopped/closed. In case of playback the power down is delayed (5 sec by default) In case of capture the power down is instant.
If you stop, and restart the playback stream within 5 sec, events will not be triggered on the widgets, since they are still powered.
On Thu, Jan 27, 2011 at 09:09:39AM +0200, Peter Ujfalusi wrote:
If you stop, and restart the playback stream within 5 sec, events will not be triggered on the widgets, since they are still powered.
It's worth remembering (mostly for the original poster, I know you're aware of this) that all this is completely invisible to applications. Applications should just say what they're using at any given time, the kernel will then power off as much as it can.
participants (3)
-
Harrod, John -
Mark Brown -
Peter Ujfalusi