diff mbox series

[1/2] ASoC: mt6359: skip first time data at the beginning of DMIC recording

Message ID 1603521686-13036-2-git-send-email-jiaxin.yu@mediatek.com
State New, archived
Headers show
Series ASoC: mt6359: skip first time data at the beginning of DMIC recording | expand

Commit Message

Jiaxin Yu Oct. 24, 2020, 6:41 a.m. UTC
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(-)

Comments

Mark Brown Oct. 26, 2020, 12:33 p.m. UTC | #1
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.
Jiaxin Yu Oct. 27, 2020, 10:28 a.m. UTC | #2
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.
Mark Brown Oct. 27, 2020, 1:15 p.m. UTC | #3
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.
Jiaxin Yu Oct. 28, 2020, 9:39 a.m. UTC | #4
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 mbox series

Patch

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;