On 12/17/18 6:17 AM, Dimitris Papavasiliou wrote:
On 12/13/18 7:42 PM, Mark Brown wrote:
On Sat, Nov 24, 2018 at 10:17:49PM +0200, Dimitris Papavasiliou wrote:
discussion here. I still feel that fixing the machine driver, so
that it doesn't generate the pop at all would be desirable, as
I'm not sure whether the digital_mute callback is guaranteed to
have muted the device when the clock source takes place.
Making the machine driver more robust is definitely better, it's more
robust in case the mute is for example just a very low gain which might
still let the pop through at a lower level.
Even worse, it would let the pop through at full volume, as it
doesn't depend on the gain. Still, there doesn't seem to be a
safe way to avoid the pop altogether, as far as I can see, since
the only way I have found to avoid it, is to suspend the chip
during the switch, and I can't synchronize access to the relevant
register by the machine and CODEC drivers.
If you have any other ideas/pointers on approaches I could
investigate, please let me know.
I started prototyping a different approach where the codec driver passes
the regmap information to the clock driver. What's missing in the
patchset is the addition of a clock control in the machine driver, and
logic added so that rate change can only be done in a hw_params if
there was a complete stop and reset on a DAPM_OFF event. compile-tested
only for now.
https://github.com/plbossart/sound/commits/hifiberry/clks
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
