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

DP: Fix dp period calculation for DP modules #8462

Closed

Conversation

jxstelter
Copy link
Contributor

The OBS parameter for module could be set to higher value
than the one defined by stream output format. This could result
in wrong calculation of period parameter.
Due to this issue we observe SRC tests regression on LNL platform.

This patch adds output stream format to period calculation in addition
to the one calculated from OBS. Lower value is selected.
Also period is round down to represent integer multiple of LL ticks.

Signed-off-by: Jaroslaw Stelter [email protected]

@jxstelter jxstelter force-pushed the src-fix-dp-period-calculation branch from 26c3bce to f45eba4 Compare November 8, 2023 15:23
src/audio/module_adapter/module_adapter.c Outdated Show resolved Hide resolved
@jxstelter jxstelter force-pushed the src-fix-dp-period-calculation branch from f45eba4 to 576575f Compare November 9, 2023 11:59
@jxstelter jxstelter requested review from btian1 and lyakh November 9, 2023 12:15
@@ -107,9 +108,17 @@ int src_set_params(struct processing_module *mod, struct sof_sink *sink)
* as SRC uses period value to calculate its internal buffers,
* it must be done here, right after setting sink parameters
*/
if (dev->ipc_config.proc_domain == COMP_PROCESSING_DOMAIN_DP)
dev->period = 1000000 * sink_get_min_free_space(sink) /
if (dev->ipc_config.proc_domain == COMP_PROCESSING_DOMAIN_DP) {
Copy link
Member

Choose a reason for hiding this comment

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

@jxstelter @singalsu this looks the same as the previous patch in this PR. i.e. we could make this a helper API call to avoid duplication (but can be done as an improvement in another PR).

Copy link
Contributor

Choose a reason for hiding this comment

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

image
the calcuation for sink period is more complex than this.

src/audio/module_adapter/module_adapter.c Outdated Show resolved Hide resolved
(sink_get_rate(mod->sinks[i]) / (USEC_PER_SEC / LL_TIMER_PERIOD_US));
min_free_size = MIN(min_free_size, sink_get_min_free_space(mod->sinks[i]));

unsigned int sink_period = 1000000 * min_free_size /
Copy link
Collaborator

Choose a reason for hiding this comment

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

can this overflow? If min_free_size is a bit more than 4K, it will overflow already?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think there is no case where the minimal size will be close to 4K value.

Copy link
Contributor

Choose a reason for hiding this comment

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

take 192khz, 32 bit 8 ch with 10ms period data as example:
192 * 4 * 8 * 10 = 61440, even 1ms data size is 6144.

Copy link
Member

Choose a reason for hiding this comment

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

btw, I assume this is a one time division or do we divide on every process() ?

Copy link
Contributor

Choose a reason for hiding this comment

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

this is in prepare, so it is one time, no worry on performance.

src/audio/src/src_ipc4.c Outdated Show resolved Hide resolved
Copy link
Contributor

@btian1 btian1 left a comment

Choose a reason for hiding this comment

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

we may need implement with formula like below:

sink_period = sink_produced_samples/sample_rate * 1000000

take attached 48 --> 82 as example, when produce 98, sink_period = 98/88200 * 1000000 = 1111

@@ -240,9 +241,17 @@ static int module_adapter_dp_queue_prepare(struct comp_dev *dev)
&sink_buffer->stream.runtime_stream_params,
sizeof(sink_buffer->stream.runtime_stream_params));
/* calculate time required the module to provide OBS data portion - a period */
unsigned int sink_period = 1000000 * sink_get_min_free_space(mod->sinks[i]) /
uint32_t min_free_size =
Copy link
Contributor

Choose a reason for hiding this comment

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

@jxstelter , please specify which converter have problem.
This is quite tricky for set sink period, @singalsu have a table to show different produce.
it may not easy to set here, check below 48 -->88.2 example:
image

max is 98, we may need more discuss for SRC period setting, it is more complex than we imagine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jxstelter , please specify which converter have problem. This is quite tricky for set sink period, @singalsu have a table to show different produce. it may not easy to set here, check below 48 -->88.2 example: image

max is 98, we may need more discuss for SRC period setting, it is more complex than we imagine.

Currently the issue is observed only on LNL FPGA setup. This is because on FPGA there is much lower MCPS margin available. In that case simply Copier->SRC->Copier pipeline is affected. When sink_period is set for too high value, DP module get processing time later than it should and on FPGA it can not finish processing on time, causing glitches.
The problem is not observed on RVP yet, however it could be observed when core utilization will be much higher.

@@ -107,9 +108,17 @@ int src_set_params(struct processing_module *mod, struct sof_sink *sink)
* as SRC uses period value to calculate its internal buffers,
* it must be done here, right after setting sink parameters
*/
if (dev->ipc_config.proc_domain == COMP_PROCESSING_DOMAIN_DP)
dev->period = 1000000 * sink_get_min_free_space(sink) /
if (dev->ipc_config.proc_domain == COMP_PROCESSING_DOMAIN_DP) {
Copy link
Contributor

Choose a reason for hiding this comment

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

image
the calcuation for sink period is more complex than this.

The OBS parameter for module could be set to higher value
than the one defined by stream output format. This could result
in wrong calculation of period parameter.
Due to this issue we observe SRC tests regression on LNL platform.

This patch adds output stream format to period calculation in addition
to the one calculated from OBS. Lower value is selected.
Also period is round down to represent integer multiple of LL ticks.

Signed-off-by: Jaroslaw Stelter <[email protected]>
The OBS parameter for SRC module could be set to higher value
than the one defined by stream output format. This could result
in wrong calculation of period parameter.
Due to this issue we observe SRC tests regression on LNL platform.

This patch adds output stream format to period calculation in addition
to the one calculated from OBS. Lower value is selected.
Also period is round down to represent integer multiple of LL ticks.

Signed-off-by: Jaroslaw Stelter <[email protected]>
@jxstelter jxstelter force-pushed the src-fix-dp-period-calculation branch from 576575f to 2fcfba5 Compare November 20, 2023 14:45
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.

@jxstelter is this pending more testing before non draft ?

(sink_get_rate(mod->sinks[i]) / (USEC_PER_SEC / LL_TIMER_PERIOD_US));
min_free_size = MIN(min_free_size, sink_get_min_free_space(mod->sinks[i]));

unsigned int sink_period = 1000000 * min_free_size /
Copy link
Member

Choose a reason for hiding this comment

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

btw, I assume this is a one time division or do we divide on every process() ?

@jxstelter
Copy link
Contributor Author

@jxstelter is this pending more testing before non draft ?

Yes. Actually all tests passed with this change, but we agreed with @marcinszkudlinski, that the resolution should be different. This is WIP.

@jxstelter
Copy link
Contributor Author

Closing. Issue will be fixed different way.

@jxstelter jxstelter closed this Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants