All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Dimitris Papavasiliou <dpapavas@gmail.com>,
	Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Subject: Re: Need help fixing pop/click artifacts in an ASOC driver
Date: Tue, 18 Dec 2018 08:12:14 -0600	[thread overview]
Message-ID: <a63aa724-a513-80c3-6163-574d287cde06@linux.intel.com> (raw)
In-Reply-To: <fcb1acd1-6485-0c3d-8350-82a6f003f320@gmail.com>


On 12/18/18 5:32 AM, Dimitris Papavasiliou wrote:
> On 12/17/18 8:08 PM, Pierre-Louis Bossart wrote:
>
>> The machine driver should use clk_set_rate() and not directly handle 
>> regmap or codec stuff. If it does, or if the clock framework isn't 
>> relevant here then we can simplify all this as suggested in 
>> https://patchwork.kernel.org/patch/10444387/. What I was trying to do 
>> with the github update is to keep the clock framework, tie it closer 
>> with the codec parts with a state variable that prevents wild changes 
>> without going back to a 'safe' idle state (similar idea as PulseAudio 
>> clock changes, which can only happen when the PCM is not opened and 
>> used).
>
> I have documented, in a previous message, various approaches I tried
> to prevent the pop, which were mostly based on the assumption that the
> clock source was changed too "abruptly", or wasn't allowed to settle.
> In the end, the only state, where the clocks can be switched without a
> pop seemed to be when the chip is suspended.
>
> It would of course be great if this could be achieved in a natural
> manner, by waiting for the card to be suspended and only switching
> clocks in such a state, but I don't see how this can be achieved
> robustly.  The power management behavior is outside of the control of
> the machine driver, so it can only refuse to switch sample rate when
> it's not suspended.  Perhaps this will work in practice, but I fear it
> would break applications depending on less restrained control of the
> hardware.

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.

  reply	other threads:[~2018-12-18 14:12 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 16:37 Need help fixing pop/click artifacts in an ASOC driver Dimitris Papavasiliou
2018-11-08  1:42 ` Pierre-Louis Bossart
2018-11-08 15:18   ` Takashi Iwai
2018-11-10 15:46   ` Dimitris Papavasiliou
2018-11-14 22:06     ` Mark Brown
2018-11-14 22:50       ` Dimitris Papavasiliou
2018-11-14 23:02         ` Mark Brown
2018-11-14 23:55           ` Dimitris Papavasiliou
2018-11-15  0:33             ` Mark Brown
2018-11-15 11:25               ` Dimitris Papavasiliou
2018-11-15 19:04                 ` Mark Brown
2018-11-18 13:37                   ` Dimitris Papavasiliou
2018-11-24 20:17                     ` Dimitris Papavasiliou
2018-12-13 17:42                       ` Mark Brown
2018-12-17 12:17                         ` Dimitris Papavasiliou
2018-12-17 12:37                           ` Mark Brown
2018-12-17 12:58                             ` Dimitris Papavasiliou
2018-12-17 14:10                               ` Mark Brown
2018-12-17 15:03                                 ` Dimitris Papavasiliou
2018-12-17 15:40                                   ` Mark Brown
2018-12-17 16:23                                     ` Dimitris Papavasiliou
2018-12-17 16:52                                       ` Mark Brown
2018-12-18 10:39                                         ` Dimitris Papavasiliou
2018-12-19 16:19                                           ` Mark Brown
2018-12-19 21:44                                             ` Dimitris Papavasiliou
2018-12-20 15:36                                               ` Mark Brown
2018-12-20 20:41                                                 ` Dimitris Papavasiliou
2018-12-21 10:57                                                   ` Mark Brown
2018-12-21 13:05                                                     ` Dimitris Papavasiliou
2018-12-21 17:33                                                       ` Mark Brown
2018-12-23 20:11                                                         ` Dimitris Papavasiliou
2018-12-22 14:44                                                       ` Matthias Reichl
2018-12-23 20:15                                                         ` Dimitris Papavasiliou
2018-12-17 15:03                           ` Pierre-Louis Bossart
2018-12-17 17:39                             ` Mark Brown
2018-12-17 18:08                               ` Pierre-Louis Bossart
2018-12-17 19:02                                 ` Mark Brown
2018-12-17 19:14                                   ` Pierre-Louis Bossart
2019-01-05 19:01                                     ` Pierre-Louis Bossart
2018-12-18 11:32                                 ` Dimitris Papavasiliou
2018-12-18 14:12                                   ` Pierre-Louis Bossart [this message]
2018-12-18 17:10                                     ` Dimitris Papavasiliou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a63aa724-a513-80c3-6163-574d287cde06@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=dpapavas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.