[FEATURE][SMART_AMP] Revamp smart_amp component for adaptive solutions

[johnylin76]

Is your feature request related to a problem? Please describe.
The current smart_amp component implementation source code is named in a generic matter. It contains smart_amp.c as the role of common adapter (handling component API), and smart_amp_[generic|maxim_dsm].c for generic and Maxim DSM solution respectively. However, the implementation inside doesn't perform in the same manner. The design is deeply bound to Maxim DSM solution, which is not surprising since Maxim is the initial author and there is no other solution supported for a long time.

Describe the solution you'd like
Revamp smart_amp to be in a generic matter, and adaptive to other solutions.
The expected framework would be alike module_adapter.

Describe alternatives you've considered

1. ask the new solution provider to create another smart_amp component and keep the present one untouched.
   • cons: will produce code duplication
2. implement the new smart_amp solution by module_adapter. Given that there is the on-going project to convert existing components into modules with module_adapter
   • cons: not sure about the feasibility since amart_amp is multi-input (2 source, 1 sink) component

[johnylin76]

Hi @lgirdwood ,
This issue needs your input especially for the 2nd point of alternatives.

If the on-going plan in mainstream is to migrate the processing components to module_adapter form, would you suggest to do smart_amp revamp task for adapting new smart_amp solution?
Does module_adapter support multiple source or sink already?

[johnylin76]

• @cujomalainey for viz

[cujomalainey]

@ranj063 I believe I heard your name come up last time I talked about this, feel free to unsubscribe if I am having a mental cache miss.

[lgirdwood]

@johnylin76 sorry for delay, yeah I agree - a generic smart amp layer would be the best option. We already have the "dummy" smart amp logic which could be modified to become a generic layer. Today the dummy smart amp just copies data, so its probably a good starting point. Also adding @lyakh @aiChaoSONG @mengdonglin. Think it may be too tight to squeeze this in for v2.7, v2.8 probably more resonable.

[johnylin76]

@lgirdwood Thanks for the advice.
As for the dummy smart amp mentioned above, you mean smart_amp_test implementation, is that correct?
That is indeed a good example to make the nifty re-cut for the present smart_amp implementation, picking out maxim-specific codes from the generic layer.
It is probably not a complicated task, I am happy to help if you don't mind.

[lgirdwood]

@lgirdwood Thanks for the advice. As for the dummy smart amp mentioned above, you mean smart_amp_test implementation, is that correct? That is indeed a good example to make the nifty re-cut for the present smart_amp implementation, picking out maxim-specific codes from the generic layer. It is probably not a complicated task, I am happy to help if you don't mind.

@lyakh can you point @johnylin76 to your latest/correct code. Thanks

[johnylin76]

#7907 is created for Kconfig hierarchy change. The code is not touched yet.
Will wait for the pointer provided by @lyakh

[lyakh]

@johnylin76 yes, https://github.com/thesofproject/sof/blob/main/src/samples/audio/smart_amp_test_ipc4.c is the smart amp test, that's currently used. What @lgirdwood meant was probably a conversion of that module to a loadable module as performed in #7867 . But so far in "main" we only have https://github.com/thesofproject/sof/blob/main/src/samples/audio/smart_amp_test_ipc4.c and https://github.com/thesofproject/sof/tree/mtl-005-drop-stable/src/audio/smart_amp

[johnylin76]

Thanks for the information.
With reference to #7867 the long-term goal looks to me is using module_adapter for all types of processing including smart_amp. I suppose that the project for unifying module_adapter use has a long way to go. Due to the production request on our side for the adaptive smart_amp solutions which targets for the near future, the code work for present smart_amp component should be still valued.

@lyakh @lgirdwood Does that make sense to you? If yes I will put it to my To-Do list then.

Thanks

[lgirdwood]

Thanks for the information. With reference to #7867 the long-term goal looks to me is using module_adapter for all types of processing including smart_amp.

Long term goal is to use the module API for all modules.

I suppose that the project for unifying module_adapter use has a long way to go. Due to the production request on our side for the adaptive smart_amp solutions which targets for the near future, the code work for present smart_amp component should be still valued.

@lyakh @lgirdwood Does that make sense to you? If yes I will put it to my To-Do list then.

Thanks

Yes, at a high level all smart amps will look very similar at the module level (to the module API, behaviour and topology), the differences will be at the 3rd party blob API. So agreed, having having a generic part for module API, topology and behaviour makes good sense, it will need a generic 3rd party API to plug into blobs.

[cujomalainey]

Yes, at a high level all smart amps will look very similar at the module level (to the module API, behaviour and topology), the differences will be at the 3rd party blob API. So agreed, having having a generic part for module API, topology and behaviour makes good sense, it will need a generic 3rd party API to plug into blobs.

Couple of Qs

1. do we plan to support all/multiple smart amps in a single build
2. do we want to support this via dynamic modules
3. is the smart amp interface its own UUID or a middle layer? The former will possibly have loading implications, i.e. if dynamic modules we may need to build into a single blob all needed DSM and load them all.

[johnylin76]

Couple of Qs

1. do we plan to support all/multiple smart amps in a single build
2. do we want to support this via dynamic modules
3. is the smart amp interface its own UUID or a middle layer? The former will possibly have loading implications, i.e. if dynamic modules we may need to build into a single blob all needed DSM and load them all.

Share with my ideas:

1. Supporting at most 1 smart amp solution in one build should be fair enough. I cannot think of any practical case requiring 2 or more smart amp solutions.
2. As a result of 1, my plan for smart amp revamp is still as a static module
3. My plan is that each solution owns its UUID for smart_amp. On FW building only one solution can be selected via Kconfig, UUID is used for making sure the selection on both FW and topology side are aligned. So the individual solution won't be misused or abused.

Unlike module_adapter which can runtime determine the inner processing, the modular design for smart_amp is only selective while building (more like the implementation choice e.g. EQIIR in generic, HIFI3, or HIFI4)