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.