test

test

Author: marcinszkudlinski

architectures/firmware/sof-common/pipeline_2_0/pipeline2_0_discussion.rst

@@ -0,0 +1,82 @@
+Pipeline 2.0 - proposal, RFC
+****************************
+
+This document describes a set of architecture changes known as “pipeline 2.0”.
+The purpose of the changes is to make the pipeline:
+
+ -  more flexible
+ -  more optimal 
+ -  more multi-core friendly
+ -  better fit to IPC4 (IPC3 backward compatibility must be maintained)
+ -  Implementation goal: try to keep as much common ipc3/4 core as possible. 
+
+initial headsup is here: https://github.com/thesofproject/sof/issues/7261, 
+
+previous version of the document here: https://github.com/orgs/thesofproject/discussions/8645
+
+
+some of the changes have already been implemented, but with a lot of workarounds i.e. in DP processing.
+
+Module scheduling
+-----------------
+
+Low Latency (LL) scheduling type
+=================================
+
+All LL modules will be called every 1ms, one-by-one, in a context of a single high-priority worker thread, staring from the first data producer to the last data consumer. All LL modules working on a single core must finish processing within 1ms and must process data in 1ms chunks. The latency of a complete modules chain (when all modules are on the same core) is 1ms.
+
+**2.0 new:** Each module should consume all available data from the input buffer(s), there must not be any data left in input buffer. There are exceptions: if a module has certain needs to keep data in buffers between cycles (like ASRC module), it may request it at binding time. In that case binding code must create a buffer that fulfill this requirement.
+
+***2.0 new***: Modules located on different cores may be freely bound and exchange data cross-core, even in case of LL-LL connection but 1) each core-cross bind will add 1ms latency to processing 2) there are certain limitations described later.
+
+Data Processing (DP) scheduling type (partially 2.0 new)
+============================================================
+
+Each module works in its own preemptible thread context, with lower priority than LL. Each of DP module’s thread has the same priority. If there are more than one module ready, the scheduler will choose a module that have the closest deadline, where a deadline is the last moment when a following module will have to start processing. Modules will be scheduled for processing when they have enough data for processing at all inputs and enough space to store results on all outputs.
+
+Current limitation/simplification: DP module must be surrounded by LL modules, there’s no possibility to connect DP to DP. DP to DP binding and proper deadline calculation is a complex task will be introduced later.
+
+A DP module may be located at different core that modules bound to it, there’s no difference in processing or latency.
+
+Sink/src interface
+======================
+
+Sink/src API is an interface for data flow between bound modules. It was introduced some time ago.
+The main principle of modules is to process audio data. To do it, a typical module needs a source to get data from and a sink to send a processed data to. In current pipeline there’s only one type of data flow, using comp_buffer/audio_stream structures and surrounding procedures.
+Pipeline 2.0 introduces an API that allows flexibility of data flow – a sink / source API.
+
+There are 2 sides of sink/source API:
+
+- **An API provider**, typically a buffer or (2.0 new) a module like DAI - a provider of sink/source api is an entity implementing all required API methods and providing a ready-to-use pointers to data to be processed / buffer to store processed data.
+
+ It is up to the provider to take care of buffer management, avoiding conflicts, taking care of cache coherency (if needed), etc. Sink/source providers may have their properties and limitations – like DAI may not be able to provide data to other cores, etc. See following chapters for details
+
+- **An API user**, typically a processing module. A user of sink/source API is an entity that simply call API methods and get a ready-to-use pointers to data for processing / buffer to store results. Api user does not need to do any extra operations with data, like taking care of cache coherency, it can just simply use provided pointers. It is up to the pipeline code to use a proper api provider. See following chapters for details.
+
+Sink/Src naming convention: **always look from the API user (not API provider) point of view**
+
+- source API is a **data source** from the point of view of the **user** of source API
+- source API is a **data destination** from the point of view of the **provider** of source API
+- sink API is a **data destination** from the point of view of the **user** of sink API
+- sink API is a **data source** from the point of view of the **provider** of sink API
+
+**(2.0 new)** In typical case a user of API is a **processing module**, a provider is **a buffer**, but there are other possibilities. If a module – for any reason – need to have an internal data buffer, it may simply optimize the flow by exposing it to the others by providing sink/src API. Typical example of such module is DAI, that needs to have an internal buffer for DMA and may provide data to next module directly, without using additional buffer in the middle.
+
+*Currently, however, there’s an optimalization in the code – DAI may use a buffer between itself and next module for its own purposes, but it is an optimalization trick/hack. Sink/Src API allows to do it in natural and flexible way.*
+
+Another example of module providing sink interface may be a mixout, accepting one stream at input, keeping data in an internal buffer, and sending them out to several other modules (identical copies) by providing several instances of source API and exposing the same data buffer to several receivers. Also a unique pair mixin-mixout may use sink/src API to expose their internal buffers to each other.
+
+Module binding
+---------------
+
+There may be 3 kinds of bindings:
+
+- entity using sink/source to entity using sink/source
+- **(2.0 new)** direct connection entity exposing sink/source to entity using sink/source
+- **(2.0 new)** entity exposing sink/source to entity exposing sink/source
+
+Entity using sink/source to entity using sink/source
+========================================================
+Typically, a module a module. This is the most natural way of binding (at current code - the only way), requires a buffer in between:
+
+