pipeline: eos: Add support for End Of Stream state

[softwarecki]

• Add support for setting the pipeline in the EOS state. Setting this state sets the except_eos flag in the pipeline, indicating that the end of data to be processed is expected.

• Add enum describing the state of a audio stream. Change the hw_params_configured field to state. A stream is initially in the
  STREAM_STATE_INITIAL state. After configuring the parameters, it transitions to the STREAM_STATE_READY state.

• Add new STREAM_STATE_END_OF_STREAM state indicating the end of a stream. Additional state STREAM_STATE_END_OF_STREAM_FLUSH indicates that end of stream has been detected, but silence is transmitted for the needs of DP modules.

• Add end of stream support to the host. When the pipeline is in the eos state and host runs out of available data, set the sink to the eos state.

• Add eos support in the function that calls the module's data processing function. If the end of the stream in the source buffer is detected, pass it to the output buffer. For DP modules, generate silence on the input after end of the stream to allow them to process the remaining data.

• Add support in mixin module to sending notification when end of stream is detected.

[Copilot]

Pull Request Overview

This PR adds comprehensive End of Stream (EOS) support to the audio pipeline system. It introduces a new pipeline state to handle end-of-stream scenarios and replaces a simple boolean flag with a state machine for tracking audio stream lifecycle.

• Adds EOS state management to pipelines with expect_eos flag and state validation
• Replaces hw_params_configured boolean with sof_audio_stream_state enum for better stream lifecycle tracking
• Implements EOS detection and handling across host, component processing, and mixin modules

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/ipc/ipc4/handler.c	Adds EOS pipeline state handling and validation logic
src/include/sof/audio/pipeline.h	Adds expect_eos boolean flag to pipeline structure
src/include/sof/audio/audio_buffer.h	Replaces hw_params_configured with state-based API functions
src/include/module/audio/source_api.h	Adds state getter function for source streams
src/include/module/audio/audio_stream.h	Defines new stream state enum replacing boolean flag
src/audio/mixin_mixout/mixin_mixout.c	Implements EOS notification handling with delay calculation
src/audio/host-zephyr.c	Adds EOS detection when host runs out of available data
src/audio/component.c	Implements EOS propagation and silence generation for DP modules

[kv2019i]

@softwarecki I'm perhaps something in the big picture, but does a pipe end in end-of-stream state? It would the code is adding EOS support but nothing in current PR seems to be actually deciding when EOS has been reached. Or did I miss it? I'd expect if we have e.g. a compressed format decoder as a module, it would know when data ends and signal EOS, but how does a component signal EOS? Is lack of data from host considered EOS (or underrun)?

[softwarecki]

@kv2019i
The EOS state is set via IPC, when software expects end of a stream. The host component detects the end of input data. Software is notified when the end of data reaches the mixin component. This behavior is consistent with the reference firmware.

[lgirdwood]

@kv2019i The EOS state is set via IPC, when software expects end of a stream. The host component detects the end of input data. Software is notified when the end of data reaches the mixin component. This behavior is consistent with the reference firmware.

Thanks @softwarecki - just some quick questions:

1. Whats the use case for EOS ? i.e. what feature does it help with - this will help when it comes to working out how we add to Linux drivers.
2. Whats the reason for mixin to send the notification ? Would it not be better for copier (since copier is on all pipelines).

[kv2019i]

Thanks @softwarecki , I didn't understand at first this extends SET_STATE to communicate EndOfStream. I think for many (most?) Linux usages, we can use delay reporting (snd_pcm_delay()) to estimate how long it takes to play out submitted PCM samples and application can send out zeroes until it knows all samples are played out (e.g. to ensure desktop/UI sounds are played out completely). E.g. with audio servers this won't be needed as they use a inactivity timer before they close off the PCM (after last application stream has closed).

In cases where app is directly using native ALSA HW devices, this could be used to implement a more reliable snd_pcm_drain(), especially when used with SOF PCMs that are connected to DSP pipeline with large internal buffers (like the deep buffer one). Our current implementation just flushes the driver visible ALSA buffer, but we don't have functionality to flush out the audio data in DSP SRAM buffers (as this hasn't really been an issue when audio servers are used).

[lgirdwood]

I think code is fine, for me we just have some readability and need to clarify the status enum (since this is the 3rd status enum).

[kv2019i]

One minor note on "inline" usage, but no blockers.

[kv2019i]

Btw why explicit "inline"? This seems like a really long function to inline and unless data pointing otherwise, I'd let the compiler choose.

[lgirdwood]

LGTM - just one open on the inline function and I think good to merge.

[lgirdwood]

@softwarecki can you check CI, could be an issue. Thanks !

[kv2019i]

Only known errors in CI, proceeding with merge.