You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: architectures/firmware/sof-common/pipeline_2_0/pipeline2_0_discussion.rst
+23-2
Original file line number
Diff line number
Diff line change
@@ -17,8 +17,6 @@ previous version of the document here: https://github.com/orgs/thesofproject/dis
17
17
18
18
some of the changes have already been implemented, but with a lot of workarounds i.e. in DP processing.
19
19
20
-
The main change for pipeline2.0 is
21
-
22
20
Module scheduling
23
21
-----------------
24
22
@@ -169,6 +167,29 @@ In current implementation there is another trigger - copy data from/to shadow bu
169
167
Module binding
170
168
----------------
171
169
170
+
In pipeline2.0 a buffer is no longer a main connector between modules, but its functionality is limited to the main purpose: a storage space for audio samples. The pipeline structure must be therefore stored using some other structures.
171
+
See "Module creation and pipeline iteration" for some details.
172
+
173
+
*other implentation details - TODO*
174
+
175
+
Buffer APIs (2.0 new)
176
+
=======================
177
+
178
+
All buffers in the system must implement 3 types of API:
179
+
- sink API (described before - exposed to a data produce module)
180
+
- source API (described before - exposed to a data consumer module)
181
+
- audio_buffer API (exposed to pipeline code, not to the modules)
182
+
183
+
Audio buffer is a "base abstract class" for all buffers in the system. It provides API required for buffer mainenance - creation, deletion, etc. This API should not be exposed to the modules.
184
+
185
+
186
+
(1.0 compatibility) before 2.0 is implemented, some features for module binding (ilke "is_walked" flag, etc.) must be also put into audio_buffer API.
187
+
188
+
Note that modules have access to sink or source API only, modules cannot use audio_buffer API because (as described) there are more types of data sources / data recievers than buffers. That generates a requirement: sink/source API must
189
+
provide all required data/functions for a module to configure and use data source. For performance reasons there may be neccessary keeping a shortcuts to certains strucures, like audio data parameters, in all APIs.
190
+
191
+
Also the pipeline code must maitain buffers using audio_buffer API only, there must not be any "side calls" to buffers code.
0 commit comments