Re: Latency of mixer reconfiguration

[Lennart Poettering <mznyfn@0pointer.de>]

On Thu, 18.02.10 10:01, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> > Now the question I have is, how should I best deal with this? I
> > currently assume that mixer volume changes are basically instantaneous
> > when I call the respective function of ALSA. But are they really? How
> > big is the latency at max? Do we need an API to query it?
> 
> For the embedded case the hardware update should happen synchronously
> with the ALSA API call to adjust the setting and begin affecting the
> played audio instantaneously.  The time taken to do the hardware update
> will be dominated by I/O costs, which will in turn depend on the bus
> used to access the codec - it'd be good if the buses could provide some
> information to ASoC to allow it to do an estimate, but at the minute
> we've got nothing really to go on.

But what would you guess? In which range will this most likely be? < 1ms? 
1ms? 10ms? 100ms? 1s? 1h? 10h? 10d? 10y?

tbh I feared less the actually IO latency but more that some PCM data
fifos might need flushing before the volume is actually updated. And
the latency of those fifos I feared might be more than a handful of
samples?

> What's more interesting from this point of view is that the update will
> affect the audio going through the chip at the current moment so there
> will be latency from the DMA chain and possibly also from the DSP chain
> within the CODEC (which may vary depending on which volume you're
> updating).
> 
> I suspect that trying to offer additional resolution in this way is more
> trouble than it's worth if you're concerned about the artifacts that are
> introduced during updates.  Providing per-channel differentiation if the
> hardware has only mono control has much fewer problems, though.

The current logic is to not do any software adjustment if the hardware
adjustment is "close enough" to the total adjustment we want to do,
tested against a threshold. Which I think is quite a reasonable
approach because it enables/disables this feature not globally, but
looks at each case and enables this logic only if it really has a
benefit.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4