sink / source API #7622

marcinszkudlinski · 2023-05-16T09:51:21Z

This introduces sink and source API

in summary: audio_stream is bind to data buffer - it contains write/read pointers etc. Has no encapsulation, so anybody can access buffer directly

Sink/source provide an API to get to the data. It does not assume the data are in any buffer etc. Usage of API is enforced. API may do anything with the data - move in memory for linearization, take care of coherency, etc.

THE POINT IS: any module that use the API may get data from many sources and send to many sources, no matter if it is a circular buffer (audio_stream), or a coherent DP queue, shared LL buffer, DAI, data linearization layer - the transition from one source/sink to another is transparent and may be done in runtime

To make transition smooth, an implementation of sink/source has been added to audio_stream.
There's also a POC - src module, with some TODOs

Sink/source API is a part of pipeline 2.0 will be required for

DP processing on secondary cores
Memory optimalization in LL modules chains

src/include/sof/audio/source_api.h

marcinszkudlinski · 2023-05-16T15:04:01Z

Still fighting with some compilations checks. Anyway - ready for review

marc-hb · 2023-05-16T16:27:42Z

Still fighting with some compilations checks.

It means this PR contains significant changes. Have you considered spreading the commits in this PR across multiple PRs?
https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html

It’s easier for reviewers to set aside a few minutes to review smaller changes several times than it is to allocate large blocks of time to review a large PR. etc.

Less "big-bang" and more "continuous" integration. Not just for compilation checks but for daily tests too.

marcinszkudlinski · 2023-05-16T16:56:58Z

Still fighting with some compilations checks.

It means this PR contains significant changes. Have you considered spreading the commits in this PR across multiple PRs? https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html

It’s easier for reviewers to set aside a few minutes to review smaller changes several times than it is to allocate large blocks of time to review a large PR. etc.

Less "big-bang" and more "continuous" integration. Not just for compilation checks but for daily tests too.

Believe me, it IS split. More changes coming soon.
Problems with compilations are because my main env is windows/MTL/west/zephyr/clang - and this part is working fine. Fighting with others

src/samples/audio/smart_amp_test_ipc3.c

lyakh

I think the API can and should be improved

src/audio/buffer.c

src/include/sof/audio/audio_stream.h

src/include/sof/audio/source_api.h

src/include/sof/audio/sink_api.h

src/include/sof/audio/module_adapter/module/module_interface.h

src/audio/CMakeLists.txt

src/audio/source_api_helper.c

All stream parameters are now available as a single structure Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

As no internals of audio_stream nor comp_buffer should be accessible directly, move all calls to buffer_fmt to API In addition, to let sink/source interface working, move the parameter to audio_stream structure Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

cujomalainey

LGTM for google files

btian1 · 2023-06-19T02:27:34Z

@btian1 size of .text is 1988bytes (decimal) more size of .rodata is 84 bytes more

before: No Start End Size Type Name 1 0xa1048000 0xa10484e4 0x4e4 TEXT .imr 2 0xa0030000 0xa003016a 0x16a TEXT .WindowVectors.text 3 0xa0030180 0xa00301a9 0x29 TEXT .Level2InterruptVector.text 4 0xa00301c0 0xa00301e9 0x29 TEXT .Level3InterruptVector.text 5 0xa0030200 0xa0030229 0x29 TEXT .DebugExceptionVector.text 6 0xa00302c0 0xa00302e9 0x29 TEXT .NMIExceptionVector.text 7 0xa0030300 0xa0030303 0x3 TEXT .KernelExceptionVector.text 8 0xa0030340 0xa0030352 0x12 TEXT .UserExceptionVector.text 9 0xa00303c0 0xa00303c6 0x6 TEXT .DoubleExceptionVector.text 10 0xa0030400 0xa0087254 0x56e54 TEXT .text 11 0xa0088000 0xa00dfbb0 0x57bb0 DATA .rodata 12 0xa00dfbb0 0xa00dff10 0x360 DATA initlevel 13 0xa00dff10 0xa00e070c 0x7fc DATA device_area 14 0xa00e070c 0xa00e0724 0x18 DATA k_p4wq_initparam_area 15 0xa00e0730 0xa00e0a06 0x2d6 DATA device_handles 16 0xa00e0a08 0xa00e0c48 0x240 DATA log_const_area 17 0xa00e0c48 0xa00e0c68 0x20 DATA log_backend_area 18 0xa00e0c68 0xa00e0cd4 0x6c DATA .fw_ready 19 0x400e0d00 0x400e2d00 0x2000 HEAP .noinit 20 0x400e2d00 0x400f05e8 0xd8e8 DATA .data 21 0x400f05f0 0x400f0720 0x130 DATA sw_isr_table 22 0x400f0720 0x400f07b2 0x92 DATA device_states 23 0x400f07b4 0x400f0a54 0x2a0 DATA pm_device_slots_area 24 0x400f0a54 0x400f0a90 0x3c DATA log_mpsc_pbuf_area 25 0x400f0a90 0x400f0a94 0x4 DATA log_msg_ptr_area 26 0x400f0a94 0x400f0aac 0x18 DATA k_heap_area 27 0x400f0aac 0x400f0abc 0x10 DATA k_sem_area 28 0xa00f0ac0 0xa00ffac0 0xf000 DATA .cached 29 0x40100000 0x401029d8 0x29d8 BSS .bss 30 0x40102a00 0x401d2a00 0xd0000 HEAP .heap_mem 31 0xa01d2a00 0xa01d3004 0x604 HEAP .unused_ram_start_marker 32 0x00020000 0x00020078 0x78 DATA .module.boot 33 0x00020078 0x000200f0 0x78 DATA .module.main 34 0x000200f0 0x00020750 0x660 DATA .static_uuid_entries 35 0x00020750 0x000207b0 0x60 DATA .static_log_entries 36 0x000207b0 0x000208e0 0x130 DATA .fw_metadata

after: Found 52 sections, listing valid sections...... No Start End Size Type Name 1 0xa1048000 0xa10484e4 0x4e4 TEXT .imr 2 0xa0030000 0xa003016a 0x16a TEXT .WindowVectors.text 3 0xa0030180 0xa00301a9 0x29 TEXT .Level2InterruptVector.text 4 0xa00301c0 0xa00301e9 0x29 TEXT .Level3InterruptVector.text 5 0xa0030200 0xa0030229 0x29 TEXT .DebugExceptionVector.text 6 0xa00302c0 0xa00302e9 0x29 TEXT .NMIExceptionVector.text 7 0xa0030300 0xa0030303 0x3 TEXT .KernelExceptionVector.text 8 0xa0030340 0xa0030352 0x12 TEXT .UserExceptionVector.text 9 0xa00303c0 0xa00303c6 0x6 TEXT .DoubleExceptionVector.text 10 0xa0030400 0xa0087a18 0x57618 TEXT .text 11 0xa0088000 0xa00dfc04 0x57c04 DATA .rodata 12 0xa00dfc04 0xa00dff64 0x360 DATA initlevel 13 0xa00dff64 0xa00e0760 0x7fc DATA device_area 14 0xa00e0760 0xa00e0778 0x18 DATA k_p4wq_initparam_area 15 0xa00e0780 0xa00e0a56 0x2d6 DATA device_handles 16 0xa00e0a58 0xa00e0c98 0x240 DATA log_const_area 17 0xa00e0c98 0xa00e0cb8 0x20 DATA log_backend_area 18 0xa00e0cb8 0xa00e0d24 0x6c DATA .fw_ready 19 0x400e0d40 0x400e2d40 0x2000 HEAP .noinit 20 0x400e2d40 0x400f0698 0xd958 DATA .data 21 0x400f06a0 0x400f07d0 0x130 DATA sw_isr_table 22 0x400f07d0 0x400f0862 0x92 DATA device_states 23 0x400f0864 0x400f0b04 0x2a0 DATA pm_device_slots_area 24 0x400f0b04 0x400f0b40 0x3c DATA log_mpsc_pbuf_area 25 0x400f0b40 0x400f0b44 0x4 DATA log_msg_ptr_area 26 0x400f0b44 0x400f0b5c 0x18 DATA k_heap_area 27 0x400f0b5c 0x400f0b6c 0x10 DATA k_sem_area 28 0xa00f0b80 0xa00ffb80 0xf000 DATA .cached 29 0x40100000 0x401029d8 0x29d8 BSS .bss 30 0x40102a00 0x401d2a00 0xd0000 HEAP .heap_mem 31 0xa01d2a00 0xa01d3004 0x604 HEAP .unused_ram_start_marker 32 0x00020000 0x00020078 0x78 DATA .module.boot 33 0x00020078 0x000200f0 0x78 DATA .module.main 34 0x000200f0 0x00020750 0x660 DATA .static_uuid_entries 35 0x00020750 0x000207b0 0x60 DATA .static_log_entries 36 0x000207b0 0x000208e0 0x130 DATA .fw_metadata

only 2k bytes adding, looks great.

lyakh · 2023-06-19T08:59:05Z

src/audio/source_api_helper.c

+#include <sof/audio/audio_stream.h>
+
+void source_init(struct source __sparse_cache *source, const struct source_ops *ops,
+		 struct sof_audio_stream_params *audio_stream_params)


maybe annotate audio_stream_params with __sparse_cache too instead of casting it out? Same for sink_init()

no, it cannot be sparse. It is up to the implementation how to ensure coherency - This pointer may be uncached - if the queue is shared between cores like dp_queue

plbossart

The intent of this PR sounds good.

I am still going to request changes for
a) naming. using just 'struct sink' is madness, you need to prefix this API to avoid conflicts
b) locking is absolutely unclear and undocumented.

plbossart · 2023-06-19T08:41:21Z

src/include/sof/audio/audio_stream.h

+
+	/** alignment limit of stream copy, this value indicates how many
+	 * integer frames which can meet both byte align and frame align
+	 * requirement. it should be set in component prepare or param functions


this comment is very very unclear. What does 'byte align' mean? What does 'frame align' mean?

I know the text is the same as before but I still can't figure out what the intent of this flag is.

Consider rewording or clarifying this field.

This is NOT my comment, I just moved frame_align from buffer.h to audio_stream.h
I don't want to "fix" audio_stream in this PR, even if in comments

@andrula-song can you please take the AR to fix those comments?
they are confusing and make little sense.
Adding @singalsu as reviewer :-)

here is the link #7833

plbossart · 2023-06-19T08:46:30Z

src/audio/copier/copier_generic.c

@@ -238,7 +237,8 @@ int create_endpoint_buffer(struct comp_dev *parent_dev,
 	audio_stream_set_rate(&buffer_c->stream, copier_cfg->base.audio_fmt.sampling_frequency);
 	audio_stream_set_frm_fmt(&buffer_c->stream, config->frame_fmt);
 	audio_stream_set_valid_fmt(&buffer_c->stream, valid_fmt);
-	buffer_c->buffer_fmt = copier_cfg->base.audio_fmt.interleaving_style;
+	audio_stream_set_buffer_fmt(&buffer_c->stream,
+				    copier_cfg->base.audio_fmt.interleaving_style);


we're clearly confusing format and interleaving style....

again - not my code, just API change
This PR is not intended to fix copier

So, I beg to disagree. YOU are adding a new set_buffer_fmt L153 which only sets the interleaving style.

Naming matters and we'd miss an opportunity to clean-up the APIs and later their implementation.

src/audio/source_api_helper.c

src/include/sof/audio/source_api.h

src/include/sof/audio/source_api_implementation.h

src/include/sof/audio/sink_api.h

src/include/sof/audio/sink_api_implementation.h

this is a definition of API to source of audio data THE SOURCE is any component in the system that have data stored somehow and can give the data outside at request. The source API does not define who and how has produced the data The user - a module - sees this as a producer that PROVIDES data for processing The IMPLEMENTATION - audio_stream, DP Queue - sees this API as a destination it must send data to Examples of components that should expose source API: - DMIC. Data are coming from the outside world, stores in tmp buffer and can be presented to the rest of the system using source_api - a memory ring buffer Data are coming from other module (usually using sink_api, but it does not matter in fact) Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

this is a definition of API to sink of audio data THE SINK is any component that can store data somehow and provide a buffer to be filled with data at request. The sink API does not define how the data will be processed/used The user - a module - sees this API as a destination it must send data to The IMPLEMENTATION - audio_stream, DP Queue - sees this as a producer that PROVIDES data for processing Examples of components that should expose SINK api - /dev/null all the data stored in sink buffer are just simply discarded - I2S sender Data stored in sink buffer will be sent to the external world - a memory ring buffer data stored in the buffer will be sent to another module (usually using source API, but it does not matter in fact). Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

There are many operations on sink/source that may be put into a common library. This is the place for it. Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

Make audio_stream capable of using pipeline2.0 sink and source API This change makes integration of sink/src api possible in incremental way Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

Target is to make all modules use sink/source API as data source and destination. However, current implementation of module adapter allows 2 other completely different interfaces to be used: "simple_copy" modules receive output_stream_buffer and input_stream_buffer table. void * data pointers from both structures point to audio_stream other fields in the structures are in fact not needed but are used "! simple_copy" modules receive output_stream_buffer and input_stream_buffer table. void * data pointers from both structures point to raw linear data to make transition smooth and easy, both legacy ways have been kept, just to make the code more clear - put at separate module API calls, Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

Module prepare is an operation that needs to set up sink and source according to needs. Therefore it must have access to sink/source handlers This commit adds handlers to API. In case the module uses legacy audio stream sink/source pointers will be NULLs and number of sinks/sources will be zero Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

This is a porting of SRC module to use sink/src API To have src fully ported there's a need to get 100% independent of audio_stream and buffer.c This step is necessary because other implementations of sink/src, like DP Queue, may not be based on buffer implementation Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

plbossart

Some improvements since the last version, more suggested below.
I don't quite get the direction of travel with all these process_ functions and zero sinks/sources, the code ends-up quite confusing to the reader.

src/include/sof/audio/source_api_implementation.h

plbossart · 2023-06-19T12:12:54Z

src/include/sof/audio/audio_stream.h

+
+	/** alignment limit of stream copy, this value indicates how many
+	 * integer frames which can meet both byte align and frame align
+	 * requirement. it should be set in component prepare or param functions


@andrula-song can you please take the AR to fix those comments?
they are confusing and make little sense.
Adding @singalsu as reviewer :-)

plbossart · 2023-06-19T12:17:09Z

src/audio/copier/copier_generic.c

@@ -238,7 +237,8 @@ int create_endpoint_buffer(struct comp_dev *parent_dev,
 	audio_stream_set_rate(&buffer_c->stream, copier_cfg->base.audio_fmt.sampling_frequency);
 	audio_stream_set_frm_fmt(&buffer_c->stream, config->frame_fmt);
 	audio_stream_set_valid_fmt(&buffer_c->stream, valid_fmt);
-	buffer_c->buffer_fmt = copier_cfg->base.audio_fmt.interleaving_style;
+	audio_stream_set_buffer_fmt(&buffer_c->stream,
+				    copier_cfg->base.audio_fmt.interleaving_style);


So, I beg to disagree. YOU are adding a new set_buffer_fmt L153 which only sets the interleaving style.

Naming matters and we'd miss an opportunity to clean-up the APIs and later their implementation.

src/audio/source_api_helper.c

src/audio/sink_api_helper.c

plbossart · 2023-06-19T12:28:12Z

src/audio/audio_stream.c

+
+	/* set the default alignment info.
+	 * set byte_align as 1 means no alignment limit on byte.
+	 * set frame_align as 1 means no alignment limit on frame.


no idea what this means either.

there is a limited calculation frame number function audio_stream_avail_frames_aligned, it use shift to replace division, the byte_align and frame_align is for shift index calculation.

src/include/sof/audio/module_adapter/module/module_interface.h

plbossart · 2023-06-19T12:33:15Z

src/include/sof/audio/module_adapter/module/module_interface.h

+				struct input_stream_buffer *input_buffers,
+				int num_input_buffers,
+				struct output_stream_buffer *output_buffers,
+				int num_output_buffers);


not fully understanding the concept of this PR, there was one process_ and now there are two process_, both deprecated. What's the direction then?

plbossart · 2023-06-19T12:36:10Z

test/cmocka/src/audio/eq_fir/eq_fir_process.c

@@ -171,7 +171,7 @@ static int setup(void **state)
 	mod->stream_params->channels = params->channels;
 	mod->period_bytes = get_frame_bytes(params->source_format, params->channels) * 48000 / 1000;

-	ret = module_prepare(mod);
+	ret = module_prepare(mod, NULL, 0, NULL, 0);


so an EQ has no sources and no sinks?

That's difficult to follow.... What is this supposed to represent?

mwasko · 2023-06-19T14:25:37Z

Since I don't see any major issues left in the comments I am going to proceed with merge.

@plbossart the PR is hanging till May so I would like to kindly ask you next time to raise questions about implementation earlier and not after the PR gets approved and is ready to move on. We have already very bad statistics on how long SOF PRs are waiting in review and last minute comments with questions are not helping to improve the situation.

plbossart · 2023-06-19T15:46:27Z

Since I don't see any major issues left in the comments I am going to proceed with merge.

@plbossart the PR is hanging till May so I would like to kindly ask you next time to raise questions about implementation earlier and not after the PR gets approved and is ready to move on. We have already very bad statistics on how long SOF PRs are waiting in review and last minute comments with questions are not helping to improve the situation.

It doesn't make my comments go away. There were a couple of bad misses, such as not having a prefix for library functions which is borderline really, and blaming the reviewer is extremely bad form in open source.

Edit: This sort of comments is also just wrong, I was one of the first ones to review this PR. Don't tell me I didn't help.

marc-hb · 2023-06-19T15:54:26Z

@marcinszkudlinski could you try to address some of the comments in new, follow-up PRs? Maybe focusing on any backwards-incompatible changes before these new APIs get widely used? My 2 cents.

lyakh · 2023-06-20T06:26:48Z

src/audio/source_api_helper.c

+{
+	source->ops = ops;
+	source->requested_read_frag_size = 0;
+	source->audio_stream_params = audio_stream_params;


@marcinszkudlinski in fact this is a bug. You call this function with an acquired object and you store a pointer to that acquired object permanently and then you use it outside of the object ownership scope. This will cause failures. Please fix in a follow up.

In case of audio_stream handlers to sink/sources are __sparse

static inline struct sof_sink __sparse_cache * audio_stream_get_sink(struct audio_stream __sparse_cache *audio_stream) { return &audio_stream->sink_api; }

That implies that the handlers may be used when buffer is aquired, and only there
This is enforced by module_adapter and there's no danger here

The only concern is academic - we keep something that should not be used without lock.
At the moment we may think about shadowing audio_stream_params in sink/source structure as a temporary sollution (till comp_buffer/audio stream is still in use), this will cost some RAM.

Next implementation (dp_queue) will keep audio_stream_params in shared, never cached memory - no shadowing needed. Other upcoming implementations - like shared LL buffer - will be used exclusively by single core (so may be safely always cached - no shadowing needed).

mwasko · 2023-06-20T07:00:24Z

It doesn't make my comments go away. There were a couple of bad misses, such as not having a prefix for library functions which is borderline really, and blaming the reviewer is extremely bad form in open source.

My intention is not to ignore your comments, they can be addressed in a follow up PRs. The problem is
situation where new review feedback is dropped weeks (sometimes months) after the PR has already been discussed and improved. I am aware that each one of us has their own work to do and response time may differ, but waiting with review for last minute has negative impact on SOF project velocity and usually is discouraging for code submitters. Of course, if there are some critical problems found in a late review then we should address them immediately but otherwise my recommendation would be to stage the improvements in a follow up PRs.

marc-hb · 2023-06-20T20:25:40Z

BTW the Zephyr project has a lot of experience with "non-technical" issues in code reviews and more recently they formalized the review process a bit and wrote it down:
https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-review-escalation

The Zephyr community is a diverse group of individuals, with different levels of commitment and priorities. As such, reviewers and maintainers may not get to a PR right away...

Don't get me wrong: I'm not saying all this process applies to SOF too. SOF is of course a different project with a different structure. However this is at the very least a very good example and most SOF developers rely on Zephyr so they must be familiar with Zephyr processes anyway.

marc-hb · 2023-06-21T20:46:15Z

Due to a complex sequence of events described in fix #7846 (please review), this PR surfaced a latent assert() override warning.

@marcinszkudlinski which toolchain do you typically use and how come it did not report this?

https://github.com/thesofproject/sof/actions/runs/5311578359/jobs/9614975368

[274/366] Building CXX object modules/sof/CMakeFiles/modules_sof.dir/D_/a/sof/sof/workspace/sof/src/audio/module_adapter/iadk/system_agent.cpp.obj
In file included from D:/a/sof/sof/workspace/sof/src/include/sof/common.h:30,
                 from D:/a/sof/sof/workspace/sof/src/include/sof/audio/sink_api.h:10,
                 from D:/a/sof/sof/workspace/sof/src/include/sof/audio/module_adapter/module/module_interface.h:17,
                 from D:/a/sof/sof/workspace/sof/src/include/sof/audio/module_adapter/iadk/iadk_module_adapter.h:19,
                 from D:/a/sof/sof/workspace/sof/src/audio/module_adapter/iadk/system_agent.cpp:22:
D:/a/sof/sof/workspace/sof/zephyr/include/rtos/panic.h:19: warning: "assert" redefined
   19 | #define assert(x) __ASSERT_NO_MSG(x)
      | 
In file included from D:/a/sof/sof/workspace/sof/src/audio/module_adapter/iadk/system_agent.cpp:16:
D:/a/sof/sof/workspace/sof/src/include/sof/audio/module_adapter/iadk/utilities/array.h:60: note: this is the location of the previous definition
   60 | #define assert(cond)
      |

marcinszkudlinski force-pushed the sink-src-public branch 2 times, most recently from cb65cf2 to 5dfb460 Compare May 16, 2023 10:55

dbaluta reviewed May 16, 2023

View reviewed changes

src/include/sof/audio/source_api.h Show resolved Hide resolved

marcinszkudlinski force-pushed the sink-src-public branch 2 times, most recently from e3995ba to 1f25e82 Compare May 16, 2023 13:42

marcinszkudlinski marked this pull request as ready for review May 16, 2023 15:04

marcinszkudlinski requested review from marc-hb, aborisovich, ranj063, jxstelter, abonislawski, tlissows, singalsu, fkwasowi, RanderWang, pblaszko, lgirdwood, plbossart, mmaka1 and lbetlej as code owners May 16, 2023 15:04

marcinszkudlinski requested a review from aiChaoSONG May 16, 2023 15:04

marcinszkudlinski force-pushed the sink-src-public branch from 1f25e82 to b847986 Compare May 16, 2023 17:07

aiChaoSONG reviewed May 17, 2023

View reviewed changes

src/samples/audio/smart_amp_test_ipc3.c Show resolved Hide resolved

lyakh requested changes May 17, 2023

View reviewed changes

marcinszkudlinski force-pushed the sink-src-public branch from b847986 to 37163f9 Compare May 17, 2023 22:20

btian1 reviewed May 18, 2023

View reviewed changes

src/audio/CMakeLists.txt Outdated Show resolved Hide resolved

src/audio/source_api_helper.c Show resolved Hide resolved

marcinszkudlinski force-pushed the sink-src-public branch from 37163f9 to 60c615f Compare May 18, 2023 10:54

marcinszkudlinski added 2 commits June 16, 2023 15:01

stream: move all stream runtime parameters to a structure

d92202b

All stream parameters are now available as a single structure Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

marcinszkudlinski force-pushed the sink-src-public branch from 50268a3 to fb16c16 Compare June 16, 2023 13:03

jxstelter approved these changes Jun 16, 2023

View reviewed changes

cujomalainey approved these changes Jun 16, 2023

View reviewed changes

btian1 approved these changes Jun 19, 2023

View reviewed changes

marcinszkudlinski requested a review from lyakh June 19, 2023 06:03

lyakh reviewed Jun 19, 2023

View reviewed changes

plbossart requested changes Jun 19, 2023

View reviewed changes

marcinszkudlinski added 7 commits June 19, 2023 13:50

pipeline2.0: introduce sink/source utilities

8e4ec75

There are many operations on sink/source that may be put into a common library. This is the place for it. Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

pipeline2.0: add source/sink api to audio_stream

0c025db

Make audio_stream capable of using pipeline2.0 sink and source API This change makes integration of sink/src api possible in incremental way Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

marcinszkudlinski force-pushed the sink-src-public branch from fb16c16 to b900d5e Compare June 19, 2023 12:01

plbossart requested changes Jun 19, 2023

View reviewed changes

mwasko merged commit 46e326f into thesofproject:main Jun 19, 2023

marcinszkudlinski deleted the sink-src-public branch June 19, 2023 14:43

lyakh reviewed Jun 20, 2023

View reviewed changes

singalsu mentioned this pull request Jun 21, 2023

Audio: DRC: Convert component to module adapter API #7621

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sink / source API #7622

sink / source API #7622

marcinszkudlinski commented May 16, 2023

marcinszkudlinski commented May 16, 2023

marc-hb commented May 16, 2023 •

edited

Loading

marcinszkudlinski commented May 16, 2023 •

edited

Loading

lyakh left a comment

cujomalainey left a comment

btian1 commented Jun 19, 2023

lyakh Jun 19, 2023

marcinszkudlinski Jun 19, 2023

plbossart left a comment

plbossart Jun 19, 2023

marcinszkudlinski Jun 19, 2023

plbossart Jun 19, 2023

andrula-song Jun 20, 2023

plbossart Jun 19, 2023

marcinszkudlinski Jun 19, 2023

plbossart Jun 19, 2023

plbossart left a comment

plbossart Jun 19, 2023

plbossart Jun 19, 2023

plbossart Jun 19, 2023

andrula-song Jun 20, 2023

plbossart Jun 19, 2023

plbossart Jun 19, 2023

mwasko commented Jun 19, 2023

plbossart commented Jun 19, 2023 •

edited

Loading

marc-hb commented Jun 19, 2023

lyakh Jun 20, 2023

marcinszkudlinski Jun 20, 2023

mwasko commented Jun 20, 2023

marc-hb commented Jun 20, 2023

marc-hb commented Jun 21, 2023

sink / source API #7622

sink / source API #7622

Conversation

marcinszkudlinski commented May 16, 2023

marcinszkudlinski commented May 16, 2023

marc-hb commented May 16, 2023 • edited Loading

marcinszkudlinski commented May 16, 2023 • edited Loading

lyakh left a comment

Choose a reason for hiding this comment

cujomalainey left a comment

Choose a reason for hiding this comment

btian1 commented Jun 19, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

plbossart left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

plbossart left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mwasko commented Jun 19, 2023

plbossart commented Jun 19, 2023 • edited Loading

marc-hb commented Jun 19, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mwasko commented Jun 20, 2023

marc-hb commented Jun 20, 2023

marc-hb commented Jun 21, 2023

marc-hb commented May 16, 2023 •

edited

Loading

marcinszkudlinski commented May 16, 2023 •

edited

Loading

plbossart commented Jun 19, 2023 •

edited

Loading