On 12/17/18 6:52 PM, Mark Brown wrote:
On Mon, Dec 17, 2018 at 06:23:43PM +0200, Dimitris Papavasiliou wrote:
I've already tried your suggestion, but unfortunately it doesn't work in the general case, as it doesn't help when the hw_params callback is called while the device is opened (but not playing).
The device being open shouldn't have any impact on the power state?
It's been a while since I tried it, but, as far as I recall, that was the observed behavior (determined via printk statements in the CODEC's set_bias_level callback). To test potential fixes, I have a script that opens the device and switches sampling rate between 44.1kHz and 48kHz every one second. It popped almost every time.
(I've also tried variations of the script where a sample is played every one second, again switching between the above sample rates and where the device is closed an reopened at every switch. The behavior is mostly the same.)
If you're positive that the expected behavior should be different, I could try it again, providing more details.
Unfortunately none of this helps. Although the chip is turned off without delay, it's turned off only while the device is closed. As soon as the device is opened, it is turned on and kept on during all subsequent hw_params calls, where clock switching takes place. The pops always get through.
I would expect the stream to be closed and reopened by most applications in between reconfigurations like that, it certainly used to be the common pattern.
If by stream you mean the device, then perhaps they do. As explained above, I test using a script, instead of using applications, such as a media player, as it's easier to reproduce the problem repeatedly at will and under controlled conditions. At any rate, a potential fix of the problem, shouldn't depend on application behavior.