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

[Dimitris Papavasiliou]

On 12/19/18 6:19 PM, Mark Brown wrote:
> If you're saying you're keeping the device open while you're doing this
> (rather than closing the stream and reconfiguring) then I'd expect
> you're going to find other hardware which has similar issues, reclocking
> the device isn't something I'd expect to be able to do glitch free.

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.

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
powered down immediately after it's closed.  This does avoid the pop
when the device gets configured right after opening it, which, as you
say, seems to be what usually happens (I checked with the SoX play
utility and the MPD), but a pop is generated if there are multiple
hw_params calls and the sample rate is changed in any but the first one
(where the device is still powered down).

This can conceivably happen (for instance the Python library I was
using, forces you to make multiple hw_params calls, in order to set
more than one parameters).  Is there some way to configure the DAPM to
power up the card right before playback starts, and power it down
right after it stops?  This would prevent pops even in such
pathological cases.

>From what I could glean from the documentation on DAPM it seems like
that might be possible via stream domain widgets, but the CODEC driver
already defines those and the device is still powered up before
playback is requested.