| Message ID | 1603521686-13036-2-git-send-email-jiaxin.yu@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ASoC: mt6359: skip first time data at the beginning of DMIC recording | expand |
On Sat, Oct 24, 2020 at 02:41:25PM +0800, Jiaxin Yu wrote: > We can choose to drop away any length of data from the beginning according > to project needs. Some projects don't want to throw away any data, because > they want to use recorded data to do echo cancellation, so they have to > make sure that they are aligned with the reference data as much as > possible. Or there are other algorithms in the upper layer to eliminate > this noise. Or some projects want to eliminate this noise form the kernel > layer. However, the minimum recommended value is 50ms to skip pop noise. This seems like something that would apply equally to all DMICs so should be done at a more general level rather than in this specific driver, for example it could be done in the DMIC driver.
On Mon, 2020-10-26 at 12:33 +0000, Mark Brown wrote: > On Sat, Oct 24, 2020 at 02:41:25PM +0800, Jiaxin Yu wrote: > > We can choose to drop away any length of data from the beginning according > > to project needs. Some projects don't want to throw away any data, because > > they want to use recorded data to do echo cancellation, so they have to > > make sure that they are aligned with the reference data as much as > > possible. Or there are other algorithms in the upper layer to eliminate > > this noise. Or some projects want to eliminate this noise form the kernel > > layer. However, the minimum recommended value is 50ms to skip pop noise. > > This seems like something that would apply equally to all DMICs so > should be done at a more general level rather than in this specific > driver, for example it could be done in the DMIC driver. Hi Brown, So you suggest that we use sound/soc/codecs/dmic.c to control the delay after recording? If so, should we add one more CODEC('dmic-codec' and 'dmic-hifi') to dmic's dai-link? It looks link dmic.c has helped us do something to control dmics.
On Tue, Oct 27, 2020 at 06:28:58PM +0800, Jiaxin Yu wrote: > On Mon, 2020-10-26 at 12:33 +0000, Mark Brown wrote: > > This seems like something that would apply equally to all DMICs so > > should be done at a more general level rather than in this specific > > driver, for example it could be done in the DMIC driver. > So you suggest that we use sound/soc/codecs/dmic.c to control the delay > after recording? > If so, should we add one more CODEC('dmic-codec' and 'dmic-hifi') to > dmic's dai-link? It looks link dmic.c has helped us do something to > control dmics. Yes, exactly.
On Tue, 2020-10-27 at 13:15 +0000, Mark Brown wrote: > On Tue, Oct 27, 2020 at 06:28:58PM +0800, Jiaxin Yu wrote: > > On Mon, 2020-10-26 at 12:33 +0000, Mark Brown wrote: > > > > This seems like something that would apply equally to all DMICs so > > > should be done at a more general level rather than in this specific > > > driver, for example it could be done in the DMIC driver. > > > So you suggest that we use sound/soc/codecs/dmic.c to control the delay > > after recording? > > If so, should we add one more CODEC('dmic-codec' and 'dmic-hifi') to > > dmic's dai-link? It looks link dmic.c has helped us do something to > > control dmics. > > Yes, exactly. Thanks, if so, then the modification is mainly in the machine driver. I will send the PATCH v2 again after you review the machine driver and merge them.
diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c index 81aafb553bdd9..9a68656a9f731 100644 --- a/sound/soc/codecs/mt6359.c +++ b/sound/soc/codecs/mt6359.c @@ -1276,6 +1276,29 @@ static int mt_mtkaif_tx_event(struct snd_soc_dapm_widget *w, return 0; } +static int mt_ul_src_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, + int event) +{ + struct snd_soc_component *cmpnt = snd_soc_dapm_to_component(w->dapm); + struct mt6359_priv *priv = snd_soc_component_get_drvdata(cmpnt); + unsigned int time = priv->ul_delay_ms; + + dev_dbg(priv->dev, "%s(), event = 0x%x\n", __func__, event); + + switch (event) { + case SND_SOC_DAPM_POST_PMU: + /* skip first time data to avoid recording pop noise */ + if (time) + usleep_range(1000 * time, 1000 * (time + 1)); + break; + default: + break; + } + + return 0; +} + static int mt_ul_src_dmic_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) @@ -2050,9 +2073,8 @@ static const struct snd_soc_dapm_widget mt6359_dapm_widgets[] = { SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), SND_SOC_DAPM_SUPPLY_S("UL_SRC", SUPPLY_SEQ_UL_SRC, - MT6359_AFE_UL_SRC_CON0_L, - UL_SRC_ON_TMP_CTL_SFT, 0, - NULL, 0), + MT6359_AFE_UL_SRC_CON0_L, UL_SRC_ON_TMP_CTL_SFT, + 0, mt_ul_src_event, SND_SOC_DAPM_POST_PMU), SND_SOC_DAPM_SUPPLY_S("UL_SRC_DMIC", SUPPLY_SEQ_UL_SRC_DMIC, SND_SOC_NOPM, 0, 0, @@ -2062,7 +2084,7 @@ static const struct snd_soc_dapm_widget mt6359_dapm_widgets[] = { SND_SOC_DAPM_SUPPLY_S("UL_SRC_34", SUPPLY_SEQ_UL_SRC, MT6359_AFE_ADDA6_UL_SRC_CON0_L, ADDA6_UL_SRC_ON_TMP_CTL_SFT, 0, - NULL, 0), + mt_ul_src_event, SND_SOC_DAPM_POST_PMU), SND_SOC_DAPM_SUPPLY_S("UL_SRC_34_DMIC", SUPPLY_SEQ_UL_SRC_DMIC, SND_SOC_NOPM, 0, 0, @@ -2674,6 +2696,14 @@ static int mt6359_parse_dt(struct mt6359_priv *priv) priv->mux_select[MUX_MIC_TYPE_2] = MIC_TYPE_MUX_IDLE; } + ret = of_property_read_u32(np, "mediatek,ul-delay-ms", + &priv->ul_delay_ms); + if (ret) { + dev_warn(priv->dev, "%s() failed to read ul-delay-ms\n", + __func__); + priv->ul_delay_ms = 0; + } + return 0; } diff --git a/sound/soc/codecs/mt6359.h b/sound/soc/codecs/mt6359.h index 3792e534a91b6..de66e49b17011 100644 --- a/sound/soc/codecs/mt6359.h +++ b/sound/soc/codecs/mt6359.h @@ -2625,6 +2625,7 @@ struct mt6359_priv { int ana_gain[AUDIO_ANALOG_VOLUME_TYPE_MAX]; unsigned int mux_select[MUX_NUM]; unsigned int dmic_one_wire_mode; + unsigned int ul_delay_ms; int dev_counter[DEVICE_NUM]; int hp_gain_ctl; int hp_hifi_mode;
We can choose to drop away any length of data from the beginning according to project needs. Some projects don't want to throw away any data, because they want to use recorded data to do echo cancellation, so they have to make sure that they are aligned with the reference data as much as possible. Or there are other algorithms in the upper layer to eliminate this noise. Or some projects want to eliminate this noise form the kernel layer. However, the minimum recommended value is 50ms to skip pop noise. Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com> --- sound/soc/codecs/mt6359.c | 38 ++++++++++++++++++++++++++++++++++---- sound/soc/codecs/mt6359.h | 1 + 2 files changed, 35 insertions(+), 4 deletions(-)