[PATCH 0/2] ASoC: mt6359: skip first time data at the beginning of DMIC recording
This patch fixed the pop noise at the beginning of DMIC recording.
Jiaxin Yu (2): ASoC: mt6359: skip first time data at the beginning of DMIC recording dt-bindings: mediatek: mt8192: add ul-delay-ms property
.../devicetree/bindings/sound/mt6359.yaml | 6 +++ sound/soc/codecs/mt6359.c | 38 +++++++++++++++++-- sound/soc/codecs/mt6359.h | 1 + 3 files changed, 41 insertions(+), 4 deletions(-)
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(-)
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;
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.
We can choose to drop any length of data from the beginning according accroding 'ul-delay-ms'.
Signed-off-by: Jiaxin Yu jiaxin.yu@mediatek.com --- Documentation/devicetree/bindings/sound/mt6359.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mt6359.yaml b/Documentation/devicetree/bindings/sound/mt6359.yaml index a54f466f769d4..fd2d02c97fe7c 100644 --- a/Documentation/devicetree/bindings/sound/mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt6359.yaml @@ -49,6 +49,11 @@ properties: description: | Specifies the type of mic type connected to adc2
+ mediatek,ul-delay-ms: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Skip first time data at the beginning of DMIC recording + additionalProperties: false
examples: @@ -56,6 +61,7 @@ examples: mt6359codec: mt6359codec { mediatek,dmic-mode = <0>; mediatek,mic-type-0 = <2>; + mediatek,ul-delay-ms = <50>; };
...
On Sat, Oct 24, 2020 at 02:41:26PM +0800, Jiaxin Yu wrote:
We can choose to drop any length of data from the beginning according accroding 'ul-delay-ms'.
Signed-off-by: Jiaxin Yu jiaxin.yu@mediatek.com
Documentation/devicetree/bindings/sound/mt6359.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mt6359.yaml b/Documentation/devicetree/bindings/sound/mt6359.yaml index a54f466f769d4..fd2d02c97fe7c 100644 --- a/Documentation/devicetree/bindings/sound/mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt6359.yaml @@ -49,6 +49,11 @@ properties: description: | Specifies the type of mic type connected to adc2
- mediatek,ul-delay-ms:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
Skip first time data at the beginning of DMIC recording
What does 'ul' mean? Nothing tells me this is DMIC related in the name and 'ul' is not used anywhere in the description.
additionalProperties: false
examples: @@ -56,6 +61,7 @@ examples: mt6359codec: mt6359codec { mediatek,dmic-mode = <0>; mediatek,mic-type-0 = <2>;
mediatek,ul-delay-ms = <50>;...
2.18.0
On Sat, Oct 31, 2020 at 2:23 AM Rob Herring robh@kernel.org wrote:
On Sat, Oct 24, 2020 at 02:41:26PM +0800, Jiaxin Yu wrote:
- mediatek,ul-delay-ms:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
Skip first time data at the beginning of DMIC recordingWhat does 'ul' mean? Nothing tells me this is DMIC related in the name and 'ul' is not used anywhere in the description.
UL stands for Up-Link.
Please ignore the patch series. We won't implement the delay in mt6359.c. Instead, we'll leverage generic dmic.c. See https://patchwork.kernel.org/project/alsa-devel/patch/1603521686-13036-2-git... for previous discussion.
participants (4)
-
Jiaxin Yu -
Mark Brown -
Rob Herring -
Tzung-Bi Shih