[alsa-devel] Need help fixing pop/click artifacts in an ASOC driver

Dimitris Papavasiliou dpapavas at gmail.com
Tue Dec 18 18:10:23 CET 2018


On 12/18/18 4:12 PM, Pierre-Louis Bossart wrote:
> My point was that the machine driver can track DAPM events and put the 
> device in a 'safe' state on SND_SOC_DAPM_EVENT_OFF so that the rate can 
> be changed when playback restarts. I don't see what prevents us from 
> using the same config as during suspend? It's pretty common to play with 
> clocks with these events, and calling clk_disable_unprepare() could lead 
> to whatever configuration sequence is needed for pop-free restart on 
> startup.

I only wanted to point out that, given the current DAPM configuration
of the pcm512x CODEC driver (as determined from monitoring calls to
the .set_bias_level callback, which seems to be the only place where
the power state of the chip is actually manipulated), it seemed like
it wasn't necessarily turned off between sample rate changes, and that
I'm not sure there's a 'safe' state you can put it in, so that it
won't pop on the next change to the clock source, if it's powered up
at the time.

The DAPM subsystem is complex and documentation on it is scarce, but
it seems the former can be fixed.  At least it is implied that the DAC
can be turned on/off at the stream domain level, which seems to be
tied to playback starting/stopping.  If the DAC can be suspended right
after playback stops and powered back up right before playback starts
again, then I don't think anything else needs to be done to avoid
pops, as all clock switching will have been done with the device
suspended.

If this is not possible, then I'm not sure if you can put the device
in a 'safe' state, say with both clocks turned off, or the clock
reference switched away from SCK, or something like that, so that it
won't pop when the sample rate (and hence clock source) is later
changed, while the DAC is powered up.

Anyway, calling my familiarity with the internals of ASOC drivers
superficial, would probably be stretching it, so the above is
(hopefully somewhat educated) guesswork at best.  Ignore it if it
doesn't make sense.


More information about the Alsa-devel mailing list