Skip to content

Conversation

@singalsu
Copy link
Collaborator

@singalsu singalsu commented Aug 8, 2025

This PR is not yet sufficient alone to fix occasional glitches in 11.025 kHz capture but has been needed in workarounds where glitches were not observed (add volume component between host-copier and SRC or maximize every 1ms done host DMA transfer sizes).

The 2nd stage of the sample rate converter may not produce data
if the internal processing block is longer than output frames
count in a period. E.g. in 48 to 11.025 kHz capture the first
two copy() operations are not producing data to sink. Producing
the zeros can prevent xruns in the downstream pipeline.

Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
The conversion from 48 to 11.025 kHz was done with fractions
21/80 * 7/8. With denominator 80 in the first fraction the first
stage of SRC needed 80 input frames to consume source buffer
produce output internally.

The change to fractions 7/20 * 21/32 helps to start consuming
source buffer in the first copy. However due to 32 frames (at
intermediate 16.8 kHz) need for second stage to process the
sink buffer fill starts still after two copies. It is addressed
in another patch.

The change also impacts conversion 192 to 44.1 kHz and 96 kHz to
22.05 kHz. This change only impact the coefficients generator.
The actual coefficients change is in the next patch.

Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This change updates the actual coefficients for changed
fractions for 11.025 kHz. The purpose of the change is
to consume and produce slightly data with less jitter
in amount of data.

Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
#include "src_ipc4_int32_21_32_4535_5000.h"
#include "src_ipc4_int32_21_40_2381_5000.h"
#include "src_ipc4_int32_21_40_3968_5000.h"
#include "src_ipc4_int32_21_80_3968_5000.h"
Copy link
Collaborator Author

@singalsu singalsu Aug 8, 2025

Choose a reason for hiding this comment

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

Should git rm this header that is not needed.

@singalsu
Copy link
Collaborator Author

Seems this change is not needed, another simpler tplg patch works.

@singalsu singalsu closed this Aug 12, 2025
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.

1 participant