config: enable RTC_AEC module for LNL and PTL platforms

[tmleman]

This patch enables the Google Real Time Communication Audio Processing (RTC_AEC) module for the LNL (Lunar Lake) and PTL (Panther Lake) platforms. The RTC_AEC module is essential for performing echo-cancelling and other real-time audio processing tasks.

Changes include:

• Enabling CONFIG_COMP_GOOGLE_RTC_AUDIO_PROCESSING and CONFIG_GOOGLE_RTC_AUDIO_PROCESSING_MOCK in the intel_adsp_ace20_lnl.conf configuration file.
• Enabling CONFIG_COMP_GOOGLE_RTC_AUDIO_PROCESSING and CONFIG_GOOGLE_RTC_AUDIO_PROCESSING_MOCK in the intel_adsp_ace30_ptl.conf configuration file.

This change ensures that the RTC_AEC module is included in the firmware builds for these platforms, allowing for proper testing and functionality of real-time audio processing features.

[lgirdwood]

@lyakh could we make all the mocks into modules and then load then into CI via UUID ?

[lyakh]

@lyakh could we make all the mocks into modules and then load then into CI via UUID ?

@lgirdwood sure, but we'd need topologies that include those stub components to load and test them

[marcinszkudlinski]

@tmleman please compile AEC as a LLEXT loadable module, we don't need it in production.
@lyakh @lgirdwood MOCK is an integral part of AEC in case of testing and will be loaded together with AEC

EDIT: it may also require changes in testing, a module has to be loaded

[lyakh]

@tmleman please compile AEC as a LLEXT loadable module, we don't need it in production. @lyakh @lgirdwood MOCK is an integral part of AEC in case of testing and will be loaded together with AEC

EDIT: it may also require changes in testing, a module has to be loaded

@marcinszkudlinski so it is run-time tested in QB?

[marcinszkudlinski]

@tmleman please compile AEC as a LLEXT loadable module, we don't need it in production. @lyakh @lgirdwood MOCK is an integral part of AEC in case of testing and will be loaded together with AEC
EDIT: it may also require changes in testing, a module has to be loaded

@marcinszkudlinski so it is run-time tested in QB?

test for AEC + Mock is included in internal CI tests

[lyakh]

I'd swap the commits - first convert to "m" where already enabled, and then add directly as "m" where not enabled yet, but the result is the same

[lgirdwood]

@tmleman can you check Internal CI thanks !

[tmleman]

@lgirdwood PR must wait until the required changes in the tests are implemented. Validation is working on it.

[lgirdwood]

@lgirdwood PR must wait until the required changes in the tests are implemented. Validation is working on it

@tmleman I assume we have a valid test implemented now and its being run in CI ?

[softwarecki]

This module had an incorrect byte order in uuid, this was fixed by #9793. For me its good to merge.

[kv2019i]

@tmleman This has one quickbuild failing. Otherwise looks good for merge.

[lgirdwood]

@tmleman This has one quickbuild failing. Otherwise looks good for merge.

@tmleman ping

[tmleman]

@lgirdwood Previously, MTL CI failed in the RTC test due to an incorrect UUID. The problem was fixed by @softwarecki recent changes. Currently, the same test fails during module initialization:

[    0.692421] <inf> ipc: ipc_cmd: rx	: 0x40005000|0x12010026
[    0.692775] <wrn> ipc: ipc4_get_drv: get_drv(): the provided UUID (b780a0a6-269f-466f-b477-23dfa05af758) can't be found!
[    0.695606] <wrn> llext: llext_link_plt: PLT: cannot find idx 53 name ipc4_update_source_format
[    0.697148] <wrn> llext: llext_link_plt: PLT: cannot find idx 39 name comp_is_current_data_blob_valid
[    0.701273] <wrn> llext: llext_link_plt: PLT: cannot find idx 53 name ipc4_update_source_format
[    0.710821] <wrn> llext: llext_link_plt: PLT: cannot find idx 39 name comp_is_current_data_blob_valid
[    0.719726] <inf> llext: llext_load: Loaded extension RTC_AEC
[    0.721906] <err> lib_manager: lib_manager_module_create: lib_manager_allocate_module() failed!
[    0.721948] <err> ipc: ipc4_init_module_instance: error: failed to init module 5000 : 0
[    0.721991] <err> ipc: ipc_cmd: ipc4: MODULE_MSG failed with err 104
[    0.956415] <inf> ipc: ipc_cmd: rx	: 0x12010000|0x0

[lgirdwood]

@lgirdwood Previously, MTL CI failed in the RTC test due to an incorrect UUID. The problem was fixed by @softwarecki recent changes. Currently, the same test fails during module initialization:

[    0.692421] <inf> ipc: ipc_cmd: rx	: 0x40005000|0x12010026
[    0.692775] <wrn> ipc: ipc4_get_drv: get_drv(): the provided UUID (b780a0a6-269f-466f-b477-23dfa05af758) can't be found!
[    0.695606] <wrn> llext: llext_link_plt: PLT: cannot find idx 53 name ipc4_update_source_format
[    0.697148] <wrn> llext: llext_link_plt: PLT: cannot find idx 39 name comp_is_current_data_blob_valid
[    0.701273] <wrn> llext: llext_link_plt: PLT: cannot find idx 53 name ipc4_update_source_format
[    0.710821] <wrn> llext: llext_link_plt: PLT: cannot find idx 39 name comp_is_current_data_blob_valid
[    0.719726] <inf> llext: llext_load: Loaded extension RTC_AEC
[    0.721906] <err> lib_manager: lib_manager_module_create: lib_manager_allocate_module() failed!
[    0.721948] <err> ipc: ipc4_init_module_instance: error: failed to init module 5000 : 0
[    0.721991] <err> ipc: ipc_cmd: ipc4: MODULE_MSG failed with err 104
[    0.956415] <inf> ipc: ipc_cmd: rx	: 0x12010000|0x0

@lyakh do we need a west update ?

[lyakh]

@lgirdwood Previously, MTL CI failed in the RTC test due to an incorrect UUID. The problem was fixed by @softwarecki recent changes. Currently, the same test fails during module initialization:

[    0.692421] <inf> ipc: ipc_cmd: rx	: 0x40005000|0x12010026
[    0.692775] <wrn> ipc: ipc4_get_drv: get_drv(): the provided UUID (b780a0a6-269f-466f-b477-23dfa05af758) can't be found!
[    0.695606] <wrn> llext: llext_link_plt: PLT: cannot find idx 53 name ipc4_update_source_format
[    0.697148] <wrn> llext: llext_link_plt: PLT: cannot find idx 39 name comp_is_current_data_blob_valid
[    0.701273] <wrn> llext: llext_link_plt: PLT: cannot find idx 53 name ipc4_update_source_format
[    0.710821] <wrn> llext: llext_link_plt: PLT: cannot find idx 39 name comp_is_current_data_blob_valid
[    0.719726] <inf> llext: llext_load: Loaded extension RTC_AEC
[    0.721906] <err> lib_manager: lib_manager_module_create: lib_manager_allocate_module() failed!
[    0.721948] <err> ipc: ipc4_init_module_instance: error: failed to init module 5000 : 0
[    0.721991] <err> ipc: ipc_cmd: ipc4: MODULE_MSG failed with err 104
[    0.956415] <inf> ipc: ipc_cmd: rx	: 0x12010000|0x0

@lyakh do we need a west update ?

@lgirdwood I suppose this is an excerpt from an Internal CI log? I don't think there's anything relevant in recent Zephyr changes, that would fix this, and we don't have a topology with this module, so I cannot test, sorry. But since it's a proper reproducible error with a full log, it should be rather easy to debug

offending hunk removed

[lyakh]

This is already good, thanks, but not immediately approving yet before I ask: would it be possible to just enable CONFIG_COMP_STUBS by default on all ACE? Any objections to that? @kv2019i @lgirdwood

[lgirdwood]

This is already good, thanks, but not immediately approving yet before I ask: would it be possible to just enable CONFIG_COMP_STUBS by default on all ACE? Any objections to that? @kv2019i @lgirdwood

Do you mean build and load all stubs into DRAM for testing/CI reasons ?

[kv2019i]

@lyakh wrote:

This is already good, thanks, but not immediately approving yet before I ask: would it be possible to just enable CONFIG_COMP_STUBS by default on all ACE? Any objections to that? @kv2019i @lgirdwood

Do you mean build and load all stubs into DRAM for testing/CI reasons ?

We (still) only have one config that we use for CI and what we release. So if stubs are enabled by default, they'll be in CI and in sof-bin releases.

[lyakh]

@lyakh wrote:

This is already good, thanks, but not immediately approving yet before I ask: would it be possible to just enable CONFIG_COMP_STUBS by default on all ACE? Any objections to that? @kv2019i @lgirdwood

Do you mean build and load all stubs into DRAM for testing/CI reasons ?

We (still) only have one config that we use for CI and what we release. So if stubs are enabled by default, they'll be in CI and in sof-bin releases.

This PR already enables one of them - CONFIG_GOOGLE_RTC_AUDIO_PROCESSING_MOCK. For many of the third party modules we have 3 options: disable, enable as a mock, using our in-tree stub, or enable using the actual third party library. Obviously we cannot enable the third option because we don't have those libraries. So we can either disable those modules or enable them as mocks. This PR enables one of them as a mock in our platform configurations for LNL and PTL. What I'm asking about is whether it would be easier and better for our testing coverage to enable CONFIG_COMP_STUBS instead which would then enable all third party modules in mock mode, including this one:

config GOOGLE_RTC_AUDIO_PROCESSING_MOCK
	bool "Google Real Time Communication Audio processing mock"
	default y if COMP_STUBS

And yes, @lgirdwood this should build them as modules which then will not be included in the openmodules library, then @kv2019i we should be easily able to avoid including them in our releases?