**OBSOLETE - the newest version here:** https://github.com/thesofproject/sof-docs/pull/497 readable version: https://marcinszkudlinski.github.io/sof-docs/PAGES/architectures/firmware/sof-common/pipeline_2_0/pipeline2_0_discussion.html **Is your feature request related to a problem? Please describe.** We're heading fast for firmware fully compatible with current windows driver I order to achieve this: - IPC4 was introduced, ~~IPC3 was set as depreciated~~ - SOF component API was set as depreciated, and "Module API" was introduced - New way of scheduling (Data processing) was introduced (PR still open) To fit the requirements into current SOF code: - the pipeline itself is still controlled in IPC3 way, using a wrapper/translator to be compatible with IPC4 - the pipeline is still using component API only, a heavy and slow module adapter must be used Till now such approach was fine but is getting out of hands. Is consuming a lot of memory, is slow and with high risk of regression in legacy platforms **Describe the solution you'd like** I think there's a right moment to introduce **PIPELINE 2.0** - ~~using IPC4 natively~~ - [ ] Align/extend pipeline APIs to be IPC generic and better fit IPC4 use cases. - [ ] Align all processing to use module API and deprecate component API. WIP - trending v2.6 - [ ] LL pipeline modules should use a shared buffer and not multiple buffers. - [x] Eliminate unnecessary cache invalidation (both for audio data and metadata) unless necessary. - [x] Introduce producer-consumer safe manageable DP Queues instead of simple buffers between chunks of LL and DP modules. - [x] Introduce cache coherent shared DP-queue for modules on different cores. - [ ] Remove direction state from pipeline as source and sink are always known. The list is not 100% complete **Describe alternatives you've considered** Keep modifying current pipeline implementation. I my opinion - technical debt is now too high - high risk of introducing regression in legacy platforms **Additional context**