[BUG][MTL] High Peak/Average MCPS ratio for gain components

[mengdonglin]

Describe the bug
The Peak/Average MCPS ratio for gain components can above 6 on MTL.

To Reproduce
Run check-performance test case on the target platform

Reproduction Rate
100%

Expected behavior
Peak to average MCPS ratio should be no more than 3

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

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

   • Kernel: sof-dev 55bbc7075e68
   • SOF: main d964b7bf518d

2. Name of the topology file

   • Topology: sof-hda-generic-4ch.tplg

3. Name of the platform(s) on which the bug is observed.

   • Platform: MTL device w/ HDA or SDW

Screenshots or console output
report: https://sof-ci.ostc.intel.com/#/result/planresultdetail/31304
MTL RVP HDA (MTLP_RVP_HDA-ace1_0-ipc4)

MTL RVP with external SDW codecs on GEN4 AIOC (MTLP_SDW_AIOC-ace1_0-ipc4)

MTL DVT with SDW amplifier and DMIC codec (MTLP_SKU0C87_SDCA-ace1_0-ipc4):

[btian1]

issue rootcaused:

1. peak mcps is caused by volume ramp
2. further, take tgl platform as example, driver set ramp time as 20ms, then sof will select 125us as ramp step, means 8 times per ms(1000/125), means for a 48k playback, 6 frames will have a ramp volume, this is somehow too short.

I made below PR for as DRAFT for review, and will listen to reviewer's comments on this.
#8183

[kv2019i]

I'm not fully convinced a high peak/avg ratio is a problem if there is a clear design reason (like there is here). An algorithm can have modalities where it has a high-consumption and low-consumption states. For power consumption, the average cost is what matters. The peak consumption affects pipeline construction (peak consumption across use-case components cannot exceed DSP capacity, or audio glitches will happen). But e.g. with gain as a low-cost component, a high peak/avg ratio is not a problem.

A peak that can not be explained with algorithm design, is another matter, and suggest a bug in system behaviour or component implement. That's of course a different matter.

[btian1]

we should evaluate each algorithm's Computational complexity to determine whether it need those cycles or not.
regarding volume ramp, power calculation already fastened by look up table, left thing is: determine the ramp stepping.
this is somehow quite subjective, we may need hear and listen other people's voice.

[lgirdwood]

adding @singalsu.
Lets make sure we solve MCPS vs quality with Kconfig options to allow the user to choose his/her preference for build time config. Additionally we can use topology to allow teh user to select runtime config.

[singalsu]

adding @singalsu. Lets make sure we solve MCPS vs quality with Kconfig options to allow the user to choose his/her preference for build time config. Additionally we can use topology to allow teh user to select runtime config.

The first is possible, but I'm afraid there is no room to decrease the ramp gain update rate without negative audible impact. Setting a worse quality ramp would hide an issue if the peak really is an issue.

For the latter the topology can't impact the update rate directly. The ramp duration impacts the internally selected rate though. There's also a bug/feature that if windows fade ramp is enabled in kconfig that no other ramp type can be selected.

Ways to to improve this

• we can make capture ramps longer and have lower gain update rate there
• we don't need initial ramp in every volume instance if there are many volumes in series, should have a way to skip initial ramp but still have ramp for user adjust or mute/unmute
• we could use in Linux and Chrome OS a lighter linear ramp type, Windows fade is only requirement for Windows OS
• find optimizations to windows fade equation

[btian1]

we don't need initial ramp in every volume instance if there are many volumes in series, should have a way to skip initial ramp but still have ramp for user adjust or mute/unmute

we can first try to implement this, need find a way to find which volume need ramp, which does not.

[singalsu]

It's easy to define in topology, but we are missing IPC and topology tokens to omit initial ramp. Using the curve type as bitfield instead of enum coud be one way to extend it. There's also the SOF_VOLUME_WINDOWS_NO_FADE that could be used but it would limit the feature one curve type.