Posting wrapper code draft for Sound Research post-processing library
This is the initial wrapper code draft of Sound Research post-processing library.
Can one of the admins verify this patch?
reply test this please to run this test once
Can one of the admins verify this patch?
@EdwardAbramian2-SR The code doesn't build. I created a minimal kconfig and added sr_audio to CmakeLists.txt. I will try the block audio stream functions (to replace the read/write frag functions) with some other component.
@EdwardAbramian2-SR can you try to see if codec_adapter / module interface is usable with your API? See src/audio/codec_adapter/
@singalsu
We have no problem building our code under tgl-013-drop-stable branch, assuming our SOF_COMP_SRAUDIO is defined in topology (see the attached build log). We used that branch to compile for ASUS test unit before the target test units were available. We haven't yet attempted to build with adl-004-drop-stable branch.
@EdwardAbramian2-SR pls check your email - I've sent invite meaning future PRs will auto run the CI for you.
@singalsu
We have no problem building our code under tgl-013-drop-stable branch, assuming our SOF_COMP_SRAUDIO is defined in topology (see the attached build log). We used that branch to compile for ASUS test unit before the target test units were available. We haven't yet attempted to build with adl-004-drop-stable branch.
Yep, sr_audio seems to build OK in the log. I used main branch and own additions to kconfig and cmake, so likely my bad.
We no more use SOF_COMP_X for new development. Instead all audio processing goes to process type with generic basic IPC where only UUID identifies them. TDFB is one example of such component.
@EdwardAbramian2-SR initial build should be for ToT (main) then when you backport you make your changes functional for the target branches
@EdwardAbramian2-SR ping, do you have an ETA ? Merge window is fully open now for v2.3
No response in >1Q, closing