[alsa-devel] Using sync dapm_sync in stream_event call back

Mark Brown broonie at opensource.wolfsonmicro.com
Fri Nov 9 14:26:20 CET 2012

On Thu, Nov 08, 2012 at 04:28:43AM +0000, Babu, Ramesh wrote:

Fix your mailer to word wrap within paragraphs, not doing this makes
your messages extremely hard to read.  I've reflowed your text for

> App is re-routing the audio within codec by changing mixer settings
> (for a same stream/device).  When app changes a MUX mixer settings,
> temporarily DAPM path gets broken and shut downs BIAS/CLOCK.  I was
> planning to use a Virtual Widget which I enable in my open and disable
> it during stream_event(STREAM_STOP).  This is to make sure BIAS/CLOCK
> will never shut down, as long as stream is active.  I'm not sure if
> this is correct way to do it. Any inputs?

Open coding this at the driver level is not particularly sensible, there
is nothing driver specific about this as the same issue will apply to
any device.  It seems like a useful feature to add but should be at the
subsystem level.  Off the top of my head the simplest approach is likely
to be to add another timeout similar to the pop timer which we use to
keep supplies and biases running a little longer after their users have
been powered down.

I would at some point like to get something in the userspace API that
allows atomic updates of many controls (freeze the device, update the
controls and then unfreeze as one) which would also cover this but is
much more work.

If you are going to do this as a local hack this isn't a good way to do
it.  You should be driving the state transitions from the application
level so enabling your virtual widget before you do anything, doing your
changes and then disabling it when you're done.  This will cover a wider
range of use cases much more robustly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20121109/6fab83e5/attachment.sig>

More information about the Alsa-devel mailing list