Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipeline2.0 STEP2 - move hybrid buffering logic from comp_buffer to audio_buffer and partially place comp_buffer on top of audio_buffer #9299

Merged
merged 6 commits into from
Sep 2, 2024

Conversation

marcinszkudlinski
Copy link
Contributor

@marcinszkudlinski marcinszkudlinski commented Jul 12, 2024

  1. all logic of hybrid buffering - double buffering, currently comp_buffer <=> ring_buffer, moved to audio_buffer layer
  2. comp_buffer initially uses audio_buffer API - sink/source removed from audio_stream

next steps would be to remove all access to comp_buffer except by 3APIs: audio_buffer / sink / source
Those APIs may of course get another functions during process

@marcinszkudlinski marcinszkudlinski changed the title [DNM] Pipeline2.0 STEP2 - move hybrid buffering logic from comp_buffer to audio_buffer and partially place comp_buffer on top of audio_buffer Pipeline2.0 STEP2 - move hybrid buffering logic from comp_buffer to audio_buffer and partially place comp_buffer on top of audio_buffer Aug 9, 2024
@marcinszkudlinski marcinszkudlinski marked this pull request as ready for review August 9, 2024 09:12
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcinszkudlinski I assume there will be a flag day when we enable the Kconfig for pipeline 2.0 and this PR is just a step to that day ?

@lgirdwood lgirdwood added this to the v2.11 milestone Aug 9, 2024
@marcinszkudlinski
Copy link
Contributor Author

@lgirdwood the flag is enabled for IPC4 platforms.

  • Some features, like DP processing, require it
  • The changes in this PR are transparent for functionality
  • for legacy platforms - disabling the flag is just saving memory

Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good, ok to +1 once CI is clean. Some build warnings that need to be addressed like https://github.com/thesofproject/sof/actions/runs/10316722150/job/28559534467?pr=9299

@marcinszkudlinski marcinszkudlinski force-pushed the pipeline2_0_002 branch 4 times, most recently from 1849e86 to c7c2aec Compare August 14, 2024 15:20
@marcinszkudlinski
Copy link
Contributor Author

marcinszkudlinski commented Aug 14, 2024

fixin compilation in progress, there's still some work to do so DNM

@marc-hb marc-hb marked this pull request as draft August 14, 2024 20:41
@marc-hb marc-hb removed their request for review August 14, 2024 20:42
@marcinszkudlinski marcinszkudlinski force-pushed the pipeline2_0_002 branch 2 times, most recently from d57c4c8 to 0cbc166 Compare August 20, 2024 11:05
@marcinszkudlinski
Copy link
Contributor Author

memory leak fixed
compilation problems fixed
please proceed

@marcinszkudlinski marcinszkudlinski marked this pull request as ready for review August 20, 2024 12:41
@marc-hb
Copy link
Collaborator

marc-hb commented Aug 20, 2024

The input/output error in https://sof-ci.01.org/sofpr/PR9299/build7167/devicetest/index.html?model=LNLM_SDW_AIOC&testcase=check-capture-3times
seems completely new.

arecord: pcm_read:2221: read error: Input/output error
2024-08-20 11:24:54 UTC [REMOTE_ERROR] arecord on PCM hw:0,3 failed at 1/3.
2024-08-20 11:24:54 UTC [REMOTE_INFO] Starting func_exit_handler(1)
2024-08-20 11:24:54 UTC [REMOTE_ERROR] Starting func_exit_handler(), exit status=1, FUNCNAME stack:
2024-08-20 11:24:54 UTC [REMOTE_ERROR]  die()  @  /home/ubuntu/sof-test/test-case/../case-lib/lib.sh
2024-08-20 11:24:54 UTC [REMOTE_ERROR]  main()  @  /home/ubuntu/sof-test/test-case/check-capture.sh:101

@marc-hb
Copy link
Collaborator

marc-hb commented Aug 20, 2024

SOFCI TEST

EDIT: it's gone in https://sof-ci.01.org/sofpr/PR9299/build7192/devicetest/index.html; that newer run has only known issues...

@marcinszkudlinski
Copy link
Contributor Author

@lgirdwood @kv2019i can we proceed?

@kv2019i
Copy link
Collaborator

kv2019i commented Aug 26, 2024

@marcinszkudlinski Can you check Intel internal/quickbuild fail? That's the only thing holding back merge.

@lgirdwood
Copy link
Member

@marcinszkudlinski Can you check Intel internal/quickbuild fail? That's the only thing holding back merge.

@marcinszkudlinski Any update?

@marcinszkudlinski
Copy link
Contributor Author

@lgirdwood looks like there was a problem with FPGA testing, hopefully fixed
I'll rebase on head and will try again

cache operations are pointless when architecture is
coherent

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
secondary buffer mechanism is a feature independent of a buffer
implementation, therefore it should be located in a base class for
all buffers

this commit intentionally is not removing the same feature from
comp_buffer nor trying to use it anywhere

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
in struct audio_buffer there was only one virtual method
(free). There are probably more coming, so an ops structure
is introduced.

ring buffer which uses audio buffer as a base must adjust,
including using of an audio_buffer_init procedure, what implies
using audio_stream_params located in audio_buffer

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
comp_buffer, implemented in buffer.c file, should
be kept in the buffers directory, together with all
buffers
Also it has been renamed to comp_buffer.c

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
comp_buffer is a legacy buffer, but currently is widely
used in SOF.

During transition to pipeline2.0 there's a need that comp_buffer
expose a common API, as any other buffer

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
one variable have been forgotten during renaming
dp_queue to ring_buffer

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
@@ -128,7 +129,7 @@ endif()
add_local_sources(sof
component.c
data_blob.c
buffer.c
buffers/comp_buffer.c
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do this in the next PR if needed (as CI is good), but does it make sense to rename like other similar files to legacy-buffer.c ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

legacy-buffer.c
looks as a good idea
also struct comp_buffer ==> struct legacy_buffer
it will be a clear sign that an API is depreciated

@lgirdwood lgirdwood merged commit c72778f into thesofproject:main Sep 2, 2024
46 of 47 checks passed
secondary_buffer->audio_stream_params = buffer->audio_stream_params;
/* for performance reasons pointers to params are also kept in sink/src structures */
secondary_buffer->_sink_api.audio_stream_params = buffer->audio_stream_params;
secondary_buffer->_source_api.audio_stream_params = buffer->audio_stream_params;
Copy link
Collaborator

@lyakh lyakh Sep 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems to make 3 copies of stream parameters, so now we have 4 of them on the total? This seems really redundant. Is this a temporary situation until buffers are migrated to the new API? Maybe make one of them where it finally should be and use pointers at all other locations? TBH I'm a bit confused about the roadmap of the migration, how far we're into it and what is still left to do. @marcinszkudlinski maybe you could make a "feature" to explain the steps made so far, the current configuration (what types of buffers we currently have, what copying is done, etc.) and the roadmap?

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 3, 2024

@marcinszkudlinski maybe you could make a "feature" to explain the steps made so far, the current configuration (what types of buffers we currently have, what copying is done, etc.) and the roadmap?

Maybe like this? https://github.com/orgs/thesofproject/discussions/8645

I assumed this link was already there somewhere in the commit messages or PR description or source code comments but maybe it was missing.

@marcinszkudlinski marcinszkudlinski deleted the pipeline2_0_002 branch September 4, 2024 06:08
@marcinszkudlinski
Copy link
Contributor Author

marcinszkudlinski commented Sep 4, 2024

@lyakh @marc-hb
Yes, I need to update the doc you mention
EDIT; the most current version of the document is here
thesofproject/sof-docs#497

and readable version
https://marcinszkudlinski.github.io/sof-docs/PAGES/architectures/firmware/sof-common/pipeline_2_0/pipeline2_0_discussion.html

I add "obsolete" node to old versions

I'm doing pipeline2,0 in a "desing&implement" mode, so archeo drifts also a bit when new issues&possibilites come into my mind.

Also, I roadmap would be handy.

@lyakh
Copy link
Collaborator

lyakh commented Sep 4, 2024

and readable version https://marcinszkudlinski.github.io/sof-docs/PAGES/architectures/firmware/sof-common/pipeline_2_0/pipeline2_0_discussion.html

@marcinszkudlinski thanks, but is that outdated - I don't see it mentioning struct sof_audio_buffer at all? So now we have 3 APIs: the "original / stable / legacy" struct comp_buffer, source / sink and the new struct sof_audio_buffer? So would be good to know where we are now - which APIs are used by which components and how many additional copies get done when converting between APIs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants