Repository navigation
[BUG] THD value is larger than acceptable value #4180
Description
Describe the bug
Issue was found in:
[ICL]
11_03_TestSrcSamplingRateChange16000Hz32b32b8ch Repro: 1/75
11_03_TestSrcSamplingRateChange48000Hz32b32b4ch Repro: 1/75
[APL]
11_03_TestSrcSamplingRateChange48000Hz32b32b4ch Repro: 1/75
Topology
plb_ppl
+--------------------------------+
+------+ | +---+ +- -+ +---+ +-------+ |
| Host |----->|Buf|->|Src|->|Buf|->|SSP Dai|---+
+------+ | +---+ +-- + +---+ +-------+ | |
+--------------------------------+ |
|
cap_ppl |
+------------------+ |
+------+ | +---+ +-------+ | |
| Host |<-----|Buf|<-|SSP Dai|<----------------+
+------+ | +---+ +-------+ |
+------------------+
To Reproduce
Run tests with Diagnostic driver:
11_03_TestSrcSamplingRateChange16000Hz32b32b8ch
11_03_TestSrcSamplingRateChange48000Hz32b32b4ch
With options --playback-iterations=75
Reproduction Rate
1/75
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- SOF BRANCH: main HASH: 37d97d4
- Name of the platform(s) on which the bug is observed.
- Platform: ICL RVP, APL RVP
- Test environment:
BRANCH: master HASH: 7bc54a9c53346cea3dfc5bdedbc6a02e39597193
Screenshots or console output
ICL 11_03_TestSrcSamplingRateChange16000Hz32b32b8ch
ICL 11_03_TestSrcSamplingRateChange48000Hz32b32b4ch
APL 11_03_TestSrcSamplingRateChange48000Hz32b32b4ch
Metadata
Metadata
Assignees
Labels
Applies to Apollolake platformApplies to IceLake platformBug was seen using Python Slim driver but cant be reproduced using Linux driver.Applies to Tiger LakeSomething isn't working as expectedSlim driver / diagnostic driver issueThis issue or pull request already existsIssue/PR marked as stale and will be closed after 14 days if there is no activity.
Activity
lgirdwood commentedon May 12, 2021
@wszypelt this looks like a DMA R/W race, but it's really difficult to tell which pipeline and whether it's related to ASRC or SRC. Can you try and isolate this further. I would also like to see if a volume on capture pipeline fixes this and bridges the DMAs.
wszypelt commentedon May 12, 2021
@lgirdwood I edited the bug and left only the SRC pipeline. It should be noted that with these tests,
we convert various input formats on one topology and there is 1 output format.
Simultaneous playback and capture on external loopback (same SSP) with signal verification.
Playback pipeline contains SRC component and plays audio formats with different frequencies.
Subsequent input formats are run without destroying the current topology.
I'm not sure this answers your question. If not, please ask.
lgirdwood commentedon May 13, 2021
Duplicate of simpler #4076
kkarask commentedon Jul 21, 2021
Glitches are visible in the capture stream when SRC component is in playback and capture pipeline.
Tests which failed: 11_02_TestSrcSimpleCapture48000On16000Hz32b32b4ch and 11_01_TestSrcSimple16000On48000Hz32b32b4ch witch reproduction rate 1/75.
lgirdwood commentedon Jul 21, 2021
@kkarask can you alos test this with #4471 locally. Thanks, we think they may all be related.
kkarask commentedon Jul 22, 2021
@lgirdwood I run tests with SRC component with #4471 and found fails:
test: 11_01_TestSrcSimple16000On48000Hz32b32b8ch
glitch with reproduction rate: 1/100.
test: 11_01_TestSrcSimple16000On48000Hz24b32b4ch
glitch with reproduction rate: 1/100
lgirdwood commentedon Jul 22, 2021
Thanks again @kkarask , so for this topology it reduces the reproduction rate, but not full fix.
lgirdwood commentedon Jul 22, 2021
@kkarask do you know the buffer/period size used by the diagnostic driver on the host side, if we were to see glitches in the first 2 - 5 ms this could be explained by FW (as it uses 1ms buffers), but these glitches could be related to the size of host side buffers.
kkarask commentedon Jul 23, 2021
@lgirdwood Buffer size depends on audio format and is different in each test. For test
11_03_TestSrcSamplingRateChange16000Hz32b32b8ch buffer_size = 1024
11_03_TestSrcSamplingRateChange48000Hz32b32b4ch buffer_size = 1536
lgirdwood commentedon Jul 23, 2021
So this looks very small for a 32bit sample size * 8 channels host buffer. i.e. 1 frame is 256 bytes, so we only get 4 frames in the buffer or 240uS
Do you mean 1024 frames instead ?? This would give us 15.625 ms per buffer.
Ditto as above, could this be in frames ?
Btw, do you also know how these buffer are sent via DMA, i.e. how many chunks/periods are the buffers split into when programming the DMA ?
kkarask commentedon Jul 29, 2021
@lgirdwood Sorry, it was my mistake. I thought about buffer between components when I wrote above values.
I have checked host side buffer and it is equal to 1 MB in all tests.
lgirdwood commentedon Aug 3, 2021
Thanks 1MB makes sense. Do you know how this 1MB is partitioned into DMA descriptors ? The DMA wont send this a single 1MB chunk, but will split up the buffer to smaller chunks. We need to know the DMA chunk size for each use case (or how it is worked out).
wszypelt commentedon Aug 10, 2021
@lgirdwood
As far as I know it works like this: Diagnostic buffer is big because we handle it in test code (in python) We do it by checking the buffer in time intervals. not in interrupts.
This is irrelevant for the operation of the FW as we configure the HDA DMA via the diagnostic driver. The FW creates the input and output buffers and also configures the buffer.
If we want to send something via HDA DMA. We have our buffer, divide it into 2 parts and fill it with data from files.
After that, the process is that the HDA DMA will successively fetch the data from the buffer and we have to ensure that this data is delivered there all the time.
By dividing the buffer in half. If half of the buffer has been copied and it starts working on the second part, new data can be written to the first part.
When there is a reading, we check HDA DMA pointers.
It looks like this. We read from the read pointer to the write pointer (the write pointer that was set by HDA DMA) then update the read pointer to where we read the data.
I hope this is the answer to your question
If not, let me know please.
github-actions commentedon Jun 19, 2025
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.