[BUG] WHL DMIC capture - DC filter on startup

[singalsu]

This is a FW side copy of Linux issue thesofproject/linux#960.

On WHL it is seem that the HW gain ramp for DMIC capture is a bit too short. There's a relateively large DC "thump" waveform in the beginning.

Describe the bug
A clear and concise description of what the bug is.
What have you tried to diagnose or workaround this issue?
Please also read https://thesofproject.github.io/latest/howtos/process/bug-tracking.html for further information on submitting bugs.

To Reproduce
Steps to reproduce the behavior: (e.g. list commands or actions used to reproduce the bug)

Expected behavior
A clear and concise description of what you expected to happen.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Environment

1. Branch name and commit hash of 3 repositories: sof (firmware), linux (kernel driver) and soft (tools & topology).
2. Name of the topology file
3. Name of the platform(s) on which the bug is observed.
4. Reproducibility Rate. If you can only reproduce it randomly, it’s useful to report how many times the bug has been reproduced vs. the number of attempts it’s taken to reproduce the bug.

Screenshots or console output
If applicable, add a screenshot (drag-and-drop an image), or console logs
(cut-and-paste text and put a code fence (```) before and after, to help
explain the issue.

Please also include the relevant sections from the firmware log and kernel log in the report (and attach the full logs for complete reference). Kernel log is taken from dmesg and firmware log from sof-logger. See https://thesofproject.github.io/latest/developer_guides/debugability/logger/index.html

[lgirdwood]

@singalsu any ETA ?

[singalsu]

@lgirdwood I can do today, a very small change into dmic.h. I wasn't able to reproduce similar result as @plbossart so I need to guess a bit what the ramp time increase should be.

[lgirdwood]

@singalsu is the ramp time platform specific or device specific. Former can be a build time macro latter can come from topology. You could always have a fallback value if device specific and topology is empty..

[singalsu]

The needed ramp time depends both on platform (all cAVS are similar, after cAVS this has been enhanced for faster settling) and the used microphone model in the device (model specific plus individual variation of DC component). The ramp length has been adjusted up to follow worst case DC compensate settling happening in DMIC filter HW case so far. Since we don't have many test devices with digital microphones it's not possible to say what is the min. value for a mic model. OTOH, the full conceal of the start waveform isn't so critical.

Topology would be ideal for this but I don't have right now the math library to handle this. Since the calculation of log step needs exp() function I don't think macro processing can handle it. I have though now fixed point prototype code for fractional exp() calculation so I could have a final solution for topology in about a week for Linux and FW PRs.

The current proposed PR is quick solution.

[lgirdwood]

@singalsu ok, I guess we have matlab/octave script to generate this data ? if so, it can be included in M4 atm using Make to generate the outpt which can be included in M4. This same matlab script can then also be invoked by topology 2.0 compiler when it arrives.

[singalsu]

@lgirdwood I think a Python script could calculate in topology 2.0 scenario the unmute ramp time based on mic data sheet max DC value % and platform audio cluster version information. I don't expect build servers to have Octave available so I'd like to avoid it. The computed parameter would be a single milliseconds value for ramp length and passed as a new DMIC token to firmware driver.

Before that the fixed value e.g. 300 ms would be placed to topologies like sof-glk-da7219 and adjusted per platform if we observe something like Pierre did.

My fractional exp() function works now and it's not much code so I'm able to create a new PR for firmware (+ kernel) that can the get the milliseconds value from IPC tokens if it's > 0 and converts it to DMIC log ramp setup. If the value is zero we can use the default hardcoded ramp. Such change is backwards compatible.

new kernel, old firmware -> default ramp
old kernel, new firmware -> default ramp
new kernel, new firmware -> ramp definition from topology

Does this sound OK?

[plbossart]

I think at some point we are going to have to recognize the difference between firmware processing graph and platform hardware configuration.
Currently we stick the two pieces of information in the same topology file, but that leads to all sorts of maintenance issues. If we have two platforms with the same codec but different DMICs, we are completely hosed.

[singalsu]

Yep, though fortunately the variation in DC level settling is not so large. I think most of the needed mute time originates from platform and not from the component. The DC compensation in HW is slower than needed due to things that sometimes happen in engineering.

[singalsu]

The PR #1479 is merged so this can be closed.