[LongWang100]

There are two pops caused by SOF Firmware.

One pop occurs when switch from headphone to speaker:
When switch to headphone, audio playback data still remains in DSM processing buffer and not consumed by DMA.
So when switch back to speaker, the processing buffer is not clean, then pop noise occurs.
We can clean and reset the point for DSM internal processing buffer by called this function 'DSM_init' in function 'smart_amp_prepare'.

The other pop occurs when switch from speaker to headphone:
The feedback and feed-forward buffer processing should be independent.
But the number of frames processed by DSM feedforward is corrupted by feedback buffer calculation.
When capture pipeline exists, the number of frames for feedforward is always same as feedback.
And the number of frames for feedback is zero at the first time when the capture pipeline setup.
Then the number of frames processed by DSM feed forward is also zero though there are many frames in playback buffer.
So the available frames will become larger. It is easy to exceed the limit size of DSM input.
Then it will cause the buffer overflow and we could hear obvious pop noise from speaker.
We fix it by calculating the number of frames for feedforward and feedback respectively.

Signed-off-by: Long Wang long.wang@analog.com

[sofci]

Can one of the admins verify this patch?

reply test this please to run this test once

[gkbldcig]

Can one of the admins verify this patch?

[kv2019i]

Thank you for the patch! A few minor notes on style raised by the checkpatch check (see inline). Otherwise this looks good.

[kv2019i]

Some style and other minor issues, can you address the checkpatch findings in https://github.com/thesofproject/sof/actions/runs/4112079634/jobs/7099324790

[lgirdwood]

There are two pops caused by SOF Firmware.
@LongWang100 thanks for the patch, are you saying this bug is present in general SOF FW code or just specific to the smart AMP logic which you have fixed ?

[johnylin76]

@lgirdwood that's a good question.

It's difficult to tell. However during previous investigation we used to adopt smart_amp_test (SAMPLE_SMART_AMP=y) to run on ADL-P max98373 device, the pop noise was still able to be reproduced. Nevertheless, we had never met the pop noise issue on TGL max98373 devices.

Another thing which had confused me for a long time is that smart_amp.c sounds like to play as the role of common adapter code implementation while there exists smart_amp_maxim_dsm.c and smart_amp_generic.c for Maxim DSM and generic solution respectively. However, I then realized that smart_amp.c basically serves Maxim DSM only according that UUID is directly defined as Maxim DSM. Also, the initial author of smart_amp.c is from Maxim.

I wonder if we would expect smart_amp to be a generic component which may have various solution implementations (somewhat similar to module_adapter). If so, it will need additional (future) commits to partition the current codes into common and solution-specific parts.

[lgirdwood]

Good point @johnylin76 - we have named this in a generic matter, and some of the logic will probably be generic and the other logic will be specific for Maxim only. I think it would make sense in the future to split out and partition smart amp into generic and vendor files ? @cujomalainey @mwasko any thoughts ?

[kv2019i]

I guess there is no performance impact to doing this every time.

[lgirdwood]

@sathya-nujella fyi - we will need to backport this fix when merged ?

[lgirdwood]

There are two pops caused by SOF Firmware.
@LongWang100 thanks for the patch, are you saying this bug is present in general SOF FW code or just specific to the smart AMP logic which you have fixed ?

[lgirdwood]

test this please

[lgirdwood]

SOFCI TEST

[macchian]

@sathya-nujella fyi - we will need to backport this fix when merged ?

@sathya-nujella , @lgirdwood , yes, we need to backport this for all SoCs with max98373 smart amp.

[LongWang100]

Two checks failed. I checked the details, I found that they were not related with my submit. Anyone can help share the reason of failure checks?

/zep_workspace/zephyr/subsys/logging/backends/log_backend_adsp_mtrace.c:69:13: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/zephyr/subsys/logging/backends/log_backend_adsp_mtrace.c:73:9: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/zephyr/subsys/logging/backends/log_backend_adsp_mtrace.c:78:67: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:295:20: warning: incorrect type in initializer (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:359:20: warning: incorrect type in initializer (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:450:24: warning: incorrect type in initializer (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:451:24: warning: incorrect type in initializer (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:463:18: warning: incorrect type in assignment (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:464:18: warning: incorrect type in assignment (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:561:24: warning: incorrect type in initializer (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:562:24: warning: incorrect type in initializer (different address spaces)
/zep_workspace/zephyr/drivers/mm/mm_drv_intel_adsp_mtl_tlb.c:728:33: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/sof/src/audio/eq_iir/eq_iir.c:834:76: warning: incorrect type in argument 3 (different address spaces)
/zep_workspace/sof/src/audio/eq_iir/eq_iir.c:835:76: warning: incorrect type in argument 3 (different address spaces)
/zep_workspace/sof/src/audio/eq_iir/eq_iir.c:917:31: warning: incorrect type in argument 1 (different address spaces)
/zep_workspace/sof/src/audio/eq_iir/eq_iir.c:917:50: warning: incorrect type in argument 2 (different address spaces)

[johnylin76]

test this please

re @lgirdwood I had verified the patches on "Acer Chromebook Spin 714" (project name: kano), which is ADL-P with codec:max98373 & nau8825

[kv2019i]

@LongWang100 wrote:

Two checks failed. I checked the details, I found that they were not related with my submit. Anyone can help share the reason of failure checks?

Thanks, these are known issues with the Zephyr build and not related to your PR. I think the CI is now ok.

[kv2019i]

Thanks, looks good now.

A few style issues in the git commit, but these are not blocking:

• the title should have a prefix for the component, e.g. in this case "smart-amp: eliminate pops when switching between speaker and headphone" would have match the expected style
• the git description body does not need to be indented (see earlier git commits in the tree for reference)

But minor things, looks good for my part.

[lgirdwood]

SOFCI TEST