[alsa-devel] Disable DAPM for click avoidance ?

Mark Brown broonie at kernel.org
Wed Mar 21 03:34:32 CET 2018


On Mon, Mar 19, 2018 at 04:53:23PM +0100, Ricard Wanderlof wrote:
> On Wed, 22 Nov 2017, Mark Brown wrote:

> > The CODEC driver is broken, it shouldn't be powering off on idle if it
> > takes a second to ramp, it should be leaving VMID up while the system is
> > running - this is what the _STANDBY bias level is all about.  Look at
> > what older CODEC drivers like the wm8731 do.

> I was tracing through what actually is called in the codec driver when a 
> stream is started, and from what I can see ALSA sequences through the 
> STANDBY, PREPARE and ON states when a stream is started, with no other 
> calls to set_bias_level prior to that. So it would seem that the STANDBY 
> level is reached during the process of starting the stream, in other 
> words, VMID and the outputs would have to be enabled already in the OFF 
> state.

To repeat if you're setting idle_bias_off for a CODEC like this you're
doing it wrong.  The device shouldn't be going to a bias level lower
than _STANDBY while the system is out of suspend.

> In our system, the power consumed by the codec is negligible compared to 
> the rest of the system at all times, so it's not a problem to leave 
> basically the whole codec up, but I am trying understand what is the 
> Right Thing to do here.

Are you sure that the device doesn't have any facility for switching the
outputs to a lower power maintenance state while things are idle?  This
sounds like an extremely basic device, even by the standards of a decade
ago.  The reason for powering down the outputs isn't just a power one,
often especially with these older devices there's an audible noise floor
even when playing silence which is distracting for users in quiet
environments.  Powering down eliminates this noise floor.

The easiest thing to do if you just want to keep playing audio all the
time is to handle this in the sound server and have it keep playing.  If
the hardware really is as limited as it seems there's going to be no
good way to support it.  Without knowing how flexible it is or what
features it has it's difficult to be specific about the best way to
handle it but whatever gets done having a stream coming from the CPU all
the time will work.  The more control there is the more likely it is
that the driver is going to have to power it down on idle anyway to
allow configuration changes to be made without generating pops and
clicks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20180321/2a975adc/attachment.sig>


More information about the Alsa-devel mailing list