[alsa-devel] Need help fixing pop/click artifacts in an ASOC driver

[Dimitris Papavasiliou]

On 12/20/18 5:36 PM, Mark Brown wrote:
> On Wed, Dec 19, 2018 at 11:44:46PM +0200, Dimitris Papavasiliou wrote:
>> I got pops even if I opened the stream, called hw_params and closed it
>> on each iteration, but, as it turns out, that was in part because I
>> was being lazy, using a Python script to do the above, which sneaked
>> in a hw_params call immediately after opening the stream, to "reset"
>> it to default values.
> 
> Wow, that's...  interesting.

I'm not sure if you're referring to the Python module's behavior, or to
the fact that I was so careless and am now boring you with it, so I'm
going to assume the former. :)

>> So I've retried your suggested approach.  It looks like setting
>> .ignore_pmdown_time = 1 in the snd_soc_dai_link of the machine driver
>> is enough to cause immediate power ups/downs, but I get the following
>> behavior: The device gets powered up immediately after the first
>> hw_params call (even if nothing gets played subsequently) and it gets
> 
> Are you sure it's the hw_params() call itself?
> 
>[...]
> 
> This is what's supposed to happen.  DAPM is triggered in the prepare()
> callback, you can call hw_params() as often as you like and it should
> have no interaction with DAPM at all.

Ah, well, the explanation then probably lies in the fact that
snd_pcm_hw_params, according to the documentation also prepares the
stream:

> Install one PCM hardware configuration chosen from a configuration
> space and snd_pcm_prepare it.

As far as I can see there's no other way to call hw_params from
userspace, except for snd_pcm_set_params, which is just a wrapper that
calls snd_pcm_hw_params internally, so I suppose calling hw_params to
configure the stream, must inevitably lead to the device being powered
up.

Unfortunately the documentation ("Writing an ALSA Driver") on the
prepare callback even warns explicitly, to:

> Be careful that this callback will be called many times at each
> setup, too.

I'm not sure if this implies that configuring the card in multiple
steps when setting up the stream is expected behavior, but it could be
interpreted that way.

Should we then accept, that some pops will be generated and hope that
they'll be suppressed by the digital_mute callback?