On 12/20/18 5:36 PM, Mark Brown wrote:
On Wed, Dec 19, 2018 at 11:44:46PM +0200, Dimitris Papavasiliou wrote:
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.
I'm not sure if you're referring to the Python module's behavior, or to the fact that I was so careless and am now boring you with it, so I'm going to assume the former. :)
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?
[...]
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.
Ah, well, the explanation then probably lies in the fact that snd_pcm_hw_params, according to the documentation also prepares the stream:
Install one PCM hardware configuration chosen from a configuration space and snd_pcm_prepare it.
As far as I can see there's no other way to call hw_params from userspace, except for snd_pcm_set_params, which is just a wrapper that calls snd_pcm_hw_params internally, so I suppose calling hw_params to configure the stream, must inevitably lead to the device being powered up.
Unfortunately the documentation ("Writing an ALSA Driver") on the prepare callback even warns explicitly, to:
Be careful that this callback will be called many times at each setup, too.
I'm not sure if this implies that configuring the card in multiple steps when setting up the stream is expected behavior, but it could be interpreted that way.
Should we then accept, that some pops will be generated and hope that they'll be suppressed by the digital_mute callback?