Re: Need help fixing pop/click artifacts in an ASOC driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/15/2018 09:04 PM, Mark Brown wrote:
You can get to the CODEC driver from the machine driver, and for
idle_bias_off there's probably a good case for just setting it
unconditionally given the lack of delays.

...

That's why I'm suggesting ignore_pmdown_time as a first thing to try -
it should cause the powerdown to happen synchronously so there's no
chance for anything else to go in and change the clocking to cause a
pop.

Thanks for clarifying about idle_bias_off/ignore_pmdown_time.  As
far as I can see, idle_bias_off seems to be set by default, as
the pcm512x driver is now a component driver and idle_bias_on is
not set to true.  I've also tried to explicitly set it to false,
as well as setting use_pmdown_time to false. As far as
ignore_pmdown_time is concerned, it seems to be settable at the
dai_link level now, which is convenient for my use case.

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.

No, there's no facility for that and it's such a niche case that I'm not
convinced it's a good idea to do it.  Another thing you could do here
though is to do the bounce as part of set_sysclk() in the CODEC driver.

Regarding your suggestion to do the bounce as part of
set_sysclk() in the CODEC driver, I'm unsure how to proceed.  The
set_sysclk callback is virtually undocumented, as far as I could
see, and not supported by the pcm512x component driver.  Even if
I could support it, either my somehow filling in the component
driver callbacks from the machine driver, or by patching the
pcm512x component driver itself, if such a patch would be
acceptable, I don't see how it could help with my problem.  Since
both set_sysclk callbacks seem to operate at the CODEC or CODEC
DAI level, which knows nothing about how to switch clocks on this
particular card, I don't see how I can do the switch there, where
I can safely wrap it inside a bounce.

Maybe I'm just missing something, but as far as I can see,
there's no way to get around the need to synchronize access to
the POWER register, so as to be able to reliably power bounce the
chip while the clock selection takes place outside the
CODEC/component driver.  If such synchronization is impossible,
I'm forced to accept that the pop will be generated and rely on
suppressing it via a mute.  This can be done by implementing the
.digital_mute callback in the pcm512x component driver, for which
I have a patch, which seems to work reliably for suppressing both
the loud pop, as well as various other lower volume clicks and
pops generated by the chip.  I still feel that not generating the
pop in the first place would be preferable though.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux