DP: LL module should get 1ms data chunk in each cycle #8636
Conversation
DP may produce a huge chunk of output data (i.e. 10 LL cycles), and the following module should be able to consume it in 1 cycle chunks, one by one unfortunately LL modules are designed to drain input buffer That leads to issues when DP provide huge data portion FIX: copy only the following module's IBS in each LL cycle Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
marcinszkudlinski
requested review from
jxstelter and
ranj063
as code owners
| audio_stream_get_source(&buffer->stream); | ||
| struct sof_source *data_src = dp_queue_get_source(dp_queue); | ||
| uint32_t to_copy = MIN(sink_get_free_size(data_sink), | ||
| uint32_t to_copy = MIN(source_get_min_available(following_mod_data_source), |
There was a problem hiding this comment.
there are two possible data listed in DP output buffer:
- copy 1 LL cycle, then keep read ptr as current position, next time will start from this read ptr.
- once copy 1 LL cycle from DP output buffer, then move data from current to the beginning of the buffer.
2 will give LL modules always fetch data from beginning, i.e, linear buffer, what do you think about this?
There was a problem hiding this comment.
@marcinszkudlinski @andrula-song I assume this will always give us a size that is aligned to hifi2/3/4/5 SIMD preferred data stride ?
There was a problem hiding this comment.
from the code it is from IBS/OBS, if we don't set restrictions in tplg, there may be potential issues
sink_set_min_free_space(audio_stream_get_sink(&buffer->stream), source_src_cfg.obs); source_set_min_available(audio_stream_get_source(&buffer->stream), sink_src_cfg.ibs);
There was a problem hiding this comment.
ok, so not a problem to block this PR, but it sounds like we need a HiFi specific check around OBS/IBS as an incremental validation around IPC.
|
@marcinszkudlinski can you elaborate what issues are observed when DP provide huge data portion to next LL in path? One of the obvious problems I expect is that it will lead to MCPS spike on the following LL component that may result in LL scheduling delay, but are there any other issues? Generally to reduce latency it might be beneficial to schedule an opportunistic thread with low priority, that in each period will continue processing if there is still any data left in the LL input buffers (and cycles left on CPU). This is of course a separate topic if is a feasible option. |
|
@mwasko yes, in addition to load spikes - and possible gaps in data at last point, when LL modules cannot process bigger data portion in 1ms - there are additional problems:
|
| audio_stream_get_source(&buffer->stream); | ||
| struct sof_source *data_src = dp_queue_get_source(dp_queue); | ||
| uint32_t to_copy = MIN(sink_get_free_size(data_sink), | ||
| uint32_t to_copy = MIN(source_get_min_available(following_mod_data_source), |
There was a problem hiding this comment.
@marcinszkudlinski @andrula-song I assume this will always give us a size that is aligned to hifi2/3/4/5 SIMD preferred data stride ?
it is independent from this. It is just copying no more than IBS of a module, not to full size of a buffer. |
6 participants
DP may produce a huge chunk of output data (i.e. 10 LL cycles), and the following module should be able to consume it in 1 cycle chunks, one by one
unfortunately LL modules are designed to drain input buffer
That leads to issues when DP provide huge data portion
FIX: copy only the following module's IBS in each LL cycle