[SDW] Overshoot on RT715 record

@singalsu

when I try the latest code and UCM file, I hear a very loud pop noise when I play on RT1308 the files I recorded w/ RT715.

Looking at the file
plb.wav.gz
, this seems to be a record issue: there's a quite strong overshoot on startup, wondering if we are missing some settings in the RT715, or of we need to insert a DC component removal in the SOF topology as we do for DMICs (copying @singalsu ).

@shumingfan @bardliao can you reproduce this?

@jack-cy-yu

@jack-cy-yu loop Jack

@plbossart

@plbossart Yes I can reproduce it.

@plbossart

@plbossart I can reproduce it on my side. I am checking it with system engineer and will keep you posted.

@plbossart

@plbossart From system engineer's opinion, this overshoot is caused by DC value in DMIC, it needs some time to calibrate from its DC value to 0 by codec's filter, and from their past experience, most of overshoot issues are workaround by software. If workaround by driver is the best way, I'll send a patch for it, how do you think?

@plbossart

@plbossart From system engineer's opinion, this overshoot is caused by DC value in DMIC, it needs some time to calibrate from its DC value to 0 by codec's filter, and from their past experience, most of overshoot issues are workaround by software. If workaround by driver is the best way, I'll send a patch for it, how do you think?

@jack-cy-yu can you clarify what you mean by 'software workaround'?
For the case where the DMICs are attached to the Intel DSP, we have an IIR filter to remove the DC. @singalsu can you help describe the solution to see if we need to use the same IIR filter in the RT715 capture path in the topology?

@plbossart

@plbossart 'Software workaround' means to use delay function like msleep/usleep_range to delay the capture switch from switched On which is to bypass the calibration period of DC value. But the side effect is that some data will be lost (around 100~200ms) with this workaround. I think it's better to use IIR filter for this if IIR filter really works.

Can you try in topology that is used to use pipeline macro pipe-eq-capture.m4 instead of pipe-volume-capture.m4. I'm not sure what topology is now used but sof-icl-rt711-rt1308-rt715.m4 topology seems to use it.

The EQ capture pipe includes a +20 dB gain to compensate typical quite low sensitivity in PDM digital microphones for notebooks usage, so you should in first test in audio editor attenuate the clip by the same 20 dB to preserve the planned sensitivity. If that gives good result I can upstream another IIR coefficients set that doesn't include the gain. Also the cut-off frequency is quite low 50 Hz so there would be room to increase it a bit (maybe up to 60 - 80 Hz) for faster DC settling. Maybe also the used IIR response should be made an argument for the pipeline macro to define it at top level topology.

Below is patch for topology to change the capture pipeline macro.

diff --git a/tools/topology/sof-icl-rt711-rt1308-rt715.m4 b/tools/topology/sof-icl-rt711-rt1308-rt715.m4
index 6861e610902f..93dda3d315fb 100644
--- a/tools/topology/sof-icl-rt711-rt1308-rt715.m4
+++ b/tools/topology/sof-icl-rt711-rt1308-rt715.m4
@@ -42,7 +42,7 @@ PIPELINE_PCM_ADD(sof/pipe-volume-playback.m4,
 
 # Low Latency capture pipeline 2 on PCM 1 using max 2 channels of s32le.
 # Schedule 48 frames per 1000us deadline on core 0 with priority 0
-PIPELINE_PCM_ADD(sof/pipe-volume-capture.m4,
+PIPELINE_PCM_ADD(sof/pipe-eq-capture.m4,
        2, 1, 2, s32le,
        1000, 0, 0,
        48000, 48000, 48000)
@@ -63,7 +63,7 @@ PIPELINE_PCM_ADD(sof/pipe-volume-playback.m4,
 
 # Low Latency capture pipeline 5 on PCM 4 using max 2 channels of s32le.
 # Schedule 48 frames per 1000us deadline on core 0 with priority 0
-PIPELINE_PCM_ADD(sof/pipe-volume-capture.m4,
+PIPELINE_PCM_ADD(sof/pipe-eq-capture.m4,
        5, 4, 2, s32le,
        1000, 0, 0,
        48000, 48000, 48000)

I tried myself that but unfortunately recent edits to pipe-eq-capture.m4 allow there to be only one instance of this pipeline (a PGA is renamed to dmic0). Having two pipelines causes the topology to merge the pipelines at common "dmic0" and make things fail.

So please edit only one capture pipe that you use for testing this way and please let me know what happens!

The volume unmute ramp seems to be broken / not happening in all capture scenarios, I'll try to fix it first.

@singalsu

@singalsu @kv2019i This issue is still seen on my CML device. If you have one available, can you try a reproduce this? I am not sure what to make of the earlier feedback, the capture with RT715 is already at the right level so we don't need the 20dB boost at all.

The PR thesofproject/sof#2109 has been stuck for far too long time with non-related random CI issues. It contains the needed high-pass filter set to use here. I'll make today an update that removes the impact to KPB, hope it gets merged soon.

The needed filters are now merged to SOF. I'll make today a topology PR to address this issue.

I got a test device for loan where this can be repeated:

It's now a lot better. This the best that I can achieve with the volume linear ramp. The log ramp type would provide more attenuation to beginning but it's not yet available.

The SOF PR is now in thesofproject/sof#2302 .

The PR is now merged. Can you please check that it works as expected in your platforms!

@singalsu

looks fine now, thanks @singalsu

I see hear a lot of pop when stopping playback but that's an amplifier issue now.
well actually now that I think of it, is there a volume ramp when we stop playing? Since we don't support any drain capabilities, we probably stop without ramping down, no?

Found a RT715 record noise issue may be similar to this issue.
Noise is at the beginning of the record file. If could't hear it, please volume up the PGA5.0 5 in alsamixer capture and try it again.

CML-U and CML-H laptops can both reproduce it.

Test recipe:
Firmware: 247af13 https://github.com/thesofproject/sof/commits/master
Kernel: 6af9a26 https://github.com/bardliao/linux/tree/topic/sof-dev
tplg:
For CML-U: master branch + PR2358, sof-cml-rt711-rt1308-mono-rt715.tplg
For CML-H: master branch, sof-cml-rt711-rt1308-rt715.tplg

wav file: test.zip
Logs:
all_sof_trace.log
dmesg.log

Error not seen with master commit: 182e62a
Error still seen with master+thesofproject/sof#2358

@singalsu

looks fine now, thanks @singalsu

I see hear a lot of pop when stopping playback but that's an amplifier issue now.
well actually now that I think of it, is there a volume ramp when we stop playing? Since we don't support any drain capabilities, we probably stop without ramping down, no?

That's correct, we do not have end ramp in driver / firmware. Such could help to mitigate end pop.

Found a RT715 record noise issue may be similar to this issue.
Noise is at the beginning of the record file. If could't hear it, please volume up the PGA5.0 5 in alsamixer capture and try it again.

CML-U and CML-H laptops can both reproduce it.

Test recipe:
Firmware: 247af13 https://github.com/thesofproject/sof/commits/master
Kernel: 6af9a26 https://github.com/bardliao/linux/tree/topic/sof-dev
tplg:
For CML-U: master branch + PR2358, sof-cml-rt711-rt1308-mono-rt715.tplg
For CML-H: master branch, sof-cml-rt711-rt1308-rt715.tplg

wav file: test.zip
Logs:
all_sof_trace.log
dmesg.log

When looking at waveform it can be seen that a high-pass IIR would fix this. Also the capture volume ramp (defined by volume tokens) should be longer. Not sure if it's defined in this topology but we have in most topologies a mistake that makes the volume tokens global in the flat .conf file and the winning token is a random lottery.

I'm confused why this happens again. Is not the mute switch topology compatible with keeping the high-pass filter?

@libinyang

Issue cannot be reproduced on master branch, but can still be reproduced on cml-010-hotfix branch. @libinyang Could you please help to have a look.

Since thesofproject/sof#2358 has been merged, issue cannot be reproduced on latest sof-dev + master. So close it.

Navigation Menu

Repository navigation

[SDW] Overshoot on RT715 record #1480

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[SDW] Overshoot on RT715 record #1480

Description

Activity

shumingfan commented on Nov 13, 2019

bardliao commented on Nov 14, 2019

jack-cy-yu commented on Nov 14, 2019

jack-cy-yu commented on Nov 14, 2019

plbossart commented on Nov 14, 2019

jack-cy-yu commented on Nov 15, 2019

singalsu commented on Nov 15, 2019

singalsu commented on Nov 15, 2019

singalsu commented on Nov 20, 2019

plbossart commented on Jan 9, 2020

singalsu commented on Jan 10, 2020

3 remaining items

singalsu commented on Jan 17, 2020

singalsu commented on Jan 17, 2020

singalsu commented on Jan 17, 2020

singalsu commented on Jan 17, 2020

singalsu commented on Jan 21, 2020

plbossart commented on Feb 7, 2020

YvonneYang2 commented on Feb 21, 2020

YvonneYang2 commented on Mar 3, 2020

singalsu commented on Mar 3, 2020

singalsu commented on Mar 3, 2020

YvonneYang2 commented on Mar 5, 2020

YvonneYang2 commented on Mar 26, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions