[alsa-devel] Disable DAPM for click avoidance ?

[Mark Brown]

On Thu, Nov 23, 2017 at 10:41:33AM +0100, Ricard Wanderlof wrote:
> On Wed, 22 Nov 2017, Mark Brown wrote:
> > On Wed, Nov 22, 2017 at 01:33:37PM +0100, Ricard Wanderlof wrote:

> > Always CC maintainers on postings if you want them to be reliably
> > seen...

> Ok. I thought it was more of a general question than a maintainer question 
> but I'll keep it in mind in future.

If you don't copy any actual people the chances of getting a response
are vastly reduced.

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

> It actually does leave VMID on as soon as the codec is not at the 
> _OFF level, the problem is really that the output buffer is not enabled 
> until a playback stream is set up, and its not until the output buffer is 
> enabled that the output attains its operating level.

> Of course, one solution would be to change the driver to enable the output 
> already at the _STANDBY level. It does seem to me that that would violate 
> part of the whole point of DAPM, on the other hand, I would think that 
> at some point power management must take a second seat to actually getting 
> a good user experience.

Yes, you'll need to do something like leave the outputs enabled.  Most
devices have some facility to keep VMID switched to the outputs, though
I did see a few where someone thought it was a good idea to power on
from cold always.  A device that old isn't going to be that competitive
power wise anyway even if it were well implemented which this one seems
to not have been.

> > This is why we've got the digital_mute() callback - the idea is that the 
> > output is just going to be discarded until the interface has had a 
> > chance to settle down.

> The problems we've had have been on the CPU side, with I2S interfaces that 
> have problems synchronizing to an ongoing I2S stream when the CPU AIF is 

That's what the digital mute handling is for - we're just throwing away
any garbage the CPU puts out before it's stable.  We're not expecting it
to work around any CODEC side issues.

> in slave mode, to the extent that in some cases its impossible to 
> determine if the first sample received by or sent from the I2S interface 
> is the left or right channel. If the DAIs had been set up once and been 
> allowed to run continuously even when there is no actual audio to 
> transfer, it would have helped this situation. Agreed, I'd rather have a 
> DAI that worked properly, but sometimes one doesn't have that luxery. :-(

If you're getting L/R swap issues on some startups leaving things
enabled all the time will mean that your random swap issue gets moved to
boot.
-------------- 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/20171123/8ebb20fa/attachment.sig>