Convert the mixer component to use the module interface

[ranj063]

[lgirdwood]

@wszypelt @lrudyX can you check CI, it's timing out. Thanks!

[ranj063]

SOFCI TEST

[miRoox]

Looks like the qemu boot failure break the Jenkins job (sof-ci/jenkins/pr-qemu-boot):

[2022-09-30T04:08:46.163Z] Start QEMU Boot Test!
[2022-09-30T04:08:46.201Z] [Pipeline] echo
[2022-09-30T04:08:46.201Z] QEMU boot test on: byt
[2022-09-30T04:08:46.202Z] [Pipeline] sh
[2022-09-30T04:08:48.191Z] + set +x
[2022-09-30T04:08:49.221Z] + cmake -DTOOLCHAIN=xtensa-byt-elf -DROOT_DIR=/home/sof/work/sof.git/../xtensa-root/xtensa-byt-elf -DMEU_OPENSSL= '' '' -DINIT_CONFIG=baytrail_gcc_defconfig -DEXTRA_CFLAGS= /home/sof/work/sof.git
[2022-09-30T04:08:50.247Z] warning: the int symbol CORE_COUNT (defined at src/platform/Kconfig:307) has a non-int default MP_NUM_CPUS (undefined)
[2022-09-30T04:08:52.355Z] warning: the int symbol CORE_COUNT (defined at src/platform/Kconfig:307) has a non-int default MP_NUM_CPUS (undefined)
[2022-09-30T04:08:52.355Z] warning: the int symbol CORE_COUNT (defined at src/platform/Kconfig:307) has a non-int default MP_NUM_CPUS (undefined)
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o: in function `sys_comp_module_mixer_interface_init':
[2022-09-30T04:08:54.498Z] /home/sof/work/sof.git/src/audio/mixer/mixer.c:236: undefined reference to `module_adapter_new'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o: in function `module_mixer_interface_shim_new':
[2022-09-30T04:08:54.498Z] /home/sof/work/sof.git/src/audio/mixer/mixer.c:236: undefined reference to `module_adapter_new'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x10): undefined reference to `module_adapter_free'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x14): undefined reference to `module_adapter_params'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x20): undefined reference to `module_adapter_cmd'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x24): undefined reference to `module_adapter_trigger'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x28): undefined reference to `module_adapter_prepare'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x2c): undefined reference to `module_adapter_reset'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x30): undefined reference to `module_adapter_copy'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x38): undefined reference to `module_adapter_get_attribute'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x58): undefined reference to `module_get_large_config'
[2022-09-30T04:08:54.498Z] /home/sof/work/xtensa-byt-elf/lib/gcc/xtensa-byt-elf/10.2.0/../../../../xtensa-byt-elf/bin/ld: CMakeFiles/sof.dir/src/audio/mixer/mixer.c.o:(.rodata+0x5c): undefined reference to `module_set_large_config'
[2022-09-30T04:08:54.498Z] collect2: error: ld returned 1 exit status
[2022-09-30T04:08:54.498Z] make[3]: *** [CMakeFiles/sof.dir/build.make:1072: sof] Error 1
[2022-09-30T04:08:54.498Z] make[2]: *** [CMakeFiles/Makefile2:1879: CMakeFiles/sof.dir/all] Error 2
[2022-09-30T04:08:54.498Z] make[2]: *** Waiting for unfinished jobs....
[2022-09-30T04:08:54.498Z] make[1]: *** [CMakeFiles/Makefile2:2189: src/arch/xtensa/CMakeFiles/bin.dir/rule] Error 2
[2022-09-30T04:08:54.498Z] make: *** [Makefile:840: bin] Error 2
[2022-09-30T04:08:56.098Z] [Pipeline] echo
[2022-09-30T04:08:56.099Z] Caught: hudson.AbortException: script returned exit code 2
[2022-09-30T04:08:56.099Z] [Pipeline] echo
[2022-09-30T04:08:56.099Z] QEMU boot fail on: byt

A question: Do we still need qemu boot test for the legacy platforms like byt,cht, bdw...

[lgirdwood]

A question: Do we still need qemu boot test for the legacy platforms like byt,cht, bdw...

No, pls delete. I will now ignore CI tests for those platforms on main.

[lgirdwood]

@wszypelt @lrudyX looks like the logs are timing out. Can someone take a look thanks !

[wszypelt]

@lgirdwood Hey, a lot of tests are running today, but I have already added everything to the queue, so within 2-3 hours it should be ready

[lyakh]

Thanks for fixing, looks ok now. For my understanding: until now "simple" module adapters had 1 sink and 1 source. This PR adds support for 1 sink-many source (1:N) modules. Do we want "simple" to also support N:1? N:M?.. If yes, maybe then we want to better separate those versions? e.g. not just have a "simple" flag but a configuration variable with values like

enum sof_module_config {
ONE_2_ONE,
ONE_2_MANY,
MANY_2_ONE,
MANY_2_MANY
};

[lgirdwood]

@ranj063 any update/plan here ?

[ranj063]

Thanks for fixing, looks ok now. For my understanding: until now "simple" module adapters had 1 sink and 1 source. This PR adds support for 1 sink-many source (1:N) modules. Do we want "simple" to also support N:1? N:M?.. If yes, maybe then we want to better separate those versions? e.g. not just have a "simple" flag but a configuration variable with values like

enum sof_module_config {
ONE_2_ONE,
ONE_2_MANY,
MANY_2_ONE,
MANY_2_MANY
};

@lgirdwood @lyakh I like the new suggestion but its kind of hard to look at those configurations now without a module to test with. Can we keep that as a future assignment for now?

[ranj063]

@ranj063 any update/plan here ?

fixed conflicts now

[lyakh]

@lgirdwood @lyakh I like the new suggestion but its kind of hard to look at those configurations now without a module to test with. Can we keep that as a future assignment for now?

So you would have "simple" modules that implement one of those strategies - depending on the number of sinks and sources, and you would have "other" modules, that cannot use this "simple" API. Do you have any examples of what kinds of modules wouldn't fit in any of those 4 types?

[ranj063]

@lgirdwood @lyakh I like the new suggestion but its kind of hard to look at those configurations now without a module to test with. Can we keep that as a future assignment for now?

So you would have "simple" modules that implement one of those strategies - depending on the number of sinks and sources, and you would have "other" modules, that cannot use this "simple" API. Do you have any examples of what kinds of modules wouldn't fit in any of those 4 types?

@lyakh the quick answer is irrespective of the input:output configuration, modules that require deep buffering will not be able to do a simple copy. I think we can safely qualify all modules in the 4 types that you have called out.

[lyakh]

@lyakh the quick answer is irrespective of the input:output configuration, modules that require deep buffering will not be able to do a simple copy. I think we can safely qualify all modules in the 4 types that you have called out.

Ah, so the alternative to "simple" is "deep buffer," right? I.e. everything, that doesn't need deep buffering is "simple." Unless it is already documented somewhere and I missed it, maybe we can add a comment e.g. next to the .simple field in the structure

[lgirdwood]

@ranj063 we have a conflict, but CI was down anyway so needs a force push. Thanks.

[ranj063]

@wszypelt Can you please help with the cause for the internal CI failure?

[wszypelt]

@ranj063 It seems that we have a problem with dut and some tests fail(core 1 and 2), I'm re-testing internal intel CI

[lgirdwood]

@ranj063 It seems that we have a problem with dut and some tests fail(core 1 and 2), I'm re-testing internal intel CI

ok, thanks for checking @wszypelt - this may impact other PRs, pls let us know.

[lgirdwood]

@wszypelt can you confirm CI rerun ? if so @ranj063 might be worth checking the results again, as I'm seeing some other PRs now passing.

[wszypelt]

@lgirdwood @ranj063 a few tests unfortunately failed, probably something to fix in PR

[lgirdwood]

@ranj063 looks like still failing CI.

[wszypelt]

@ranj063 @lgirdwood Internal intel CI System passed

[singalsu]

It looks OK, this will need a revisit for demux with multiple sinks but better to take incremental steps.

[marc-hb]

Looks like the qemu boot failure break the Jenkins job (sof-ci/jenkins/pr-qemu-boot):

For the record this happens in internal Jenkins job sof_prs/2931 (and others).

The QEMU failure is a small problem, easily fixed. A much bigger problem is the inability to report errors. Validation's job is not to report successes, it's to report errors.

[kv2019i]

Seems this is good to go and the pr-device-test actually passed (test plan 19028). Proceeding with merge.

[marc-hb]

Seems this is good to go and the pr-device-test actually passed (test plan 19028). Proceeding with merge.

I'm afraid 19028 was a manual test plan, not a PR test plan. Because it triggers some internal (and serious) CI issue, merging this PR probably broke PR testing for all consecutive PRs. Working on it but please wait next time something like this happen.

[kv2019i]

@marc-hb We can also revert if this cannot be immediately addressed.