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

[Mark Brown]

On Wed, Dec 19, 2018 at 11:44:46PM +0200, Dimitris Papavasiliou wrote:
> 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.

Wow, that's...  interesting.

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

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

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.
-------------- 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/20181220/3710694f/attachment-0001.sig>