Triggering a DAPM widget event

Triggering a DAPM widget event

[Harrod, John]

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.

Re: Triggering a DAPM widget event

[Mark Brown]

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.

Re: Triggering a DAPM widget event

[Harrod, John]

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.

Re: Triggering a DAPM widget event

[Mark Brown]

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?

Re: Triggering a DAPM widget event

[Harrod, John]

> 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.

Re: Triggering a DAPM widget event

[Mark Brown]

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.

Re: Triggering a DAPM widget event

[Peter Ujfalusi]

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.

-- 
Péter

Re: Triggering a DAPM widget event

[Mark Brown]

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.