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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
