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.

Sign up for GitHub

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

Jump to bottom

[BUG] Noisy DMIC recording with concurrent audio playback over speakers #9205

Closed
syedk008 opened this issue Jun 7, 2024 · 13 comments
Closed

[BUG] Noisy DMIC recording with concurrent audio playback over speakers #9205

syedk008 opened this issue Jun 7, 2024 · 13 comments
Assignees
@lyakh @singalsu
Labels
bug Something isn't working as expected P1 Blocker bugs or important features production blocker

Comments

@syedk008
Copy link

syedk008 commented Jun 7, 2024

Describe the bug
We observed Noisy DMIC recordings with concurrent playback over speakers on the ARL-S platform.
The issue happens only with 4-channel Dmic recording but not with 2-channels.
To Reproduce
start and stop DMIC recording and playback over speakers using arecord and aplay.

  1. start playback over speakers: aplay -Dhw:0,0 -c 2 -r 48000
  2. start DMIC recording: arecord -Dhw:0,6 -f s32_LE -c 4 -r 48000
  3. wait 10 sec and stop both playback and records
  4. playback recorded file to see if any noise.
    repeat the steps several times.
    you can use the attached script to reproduce the issue.

Reproduction Rate
~25%
Expected behavior
No noise in the recording.

Impact
critical

Environment

  1. kernel: branch: sof-dev and commit:4b0046880585
    sof: v2.9 mtl
  2. Name of the topology file
    • Topology: sof-hda-generic-ace1-4ch.tplg
  3. Name of the platform(s) on which the bug is observed.
    • Platform: ARL-S

concurrent_rec_play_.txt
@syedk008 syedk008 added the bug Something isn't working as expected label Jun 7, 2024
@lgirdwood lgirdwood added the P1 Blocker bugs or important features label Jun 7, 2024
@lgirdwood lgirdwood added this to the v2.10 milestone Jun 7, 2024
@lgirdwood
Copy link
Member

@syedk008 is there any capture WAV file that you can share here ? Does it also matter if capture is started 1st then playback 2nd ?

@syedk008
Copy link
Author

syedk008 commented Jun 7, 2024

@lgirdwood attached is the WAV file, rename it to .wav.
rec.txt
I could not reproduce the issue when capture starts 1st and playback 2nd. Also the issue always in last two channels 3-4.

@singalsu
Copy link
Collaborator

Can you please try this pass-through topology version:

0001-Tools-Topology2-Add-sof-hda-generic-ace1-4ch-48k-pas.patch.gz

@singalsu
Copy link
Collaborator

Please try also this, 2ch with pdm1 (the controller that handles in 4ch channels 3-4):

0001-Tools-Topology2-Add-topology-sof-hda-generic-ace1-2c.patch.gz

@syedk008
Copy link
Author

Can you please try this pass-through topology version:

0001-Tools-Topology2-Add-sof-hda-generic-ace1-4ch-48k-pas.patch.gz

Issue is reproducible with this topology, but the frequency seems less.

@syedk008
Copy link
Author

Please try also this, 2ch with pdm1 (the controller that handles in 4ch channels 3-4):

0001-Tools-Topology2-Add-topology-sof-hda-generic-ace1-2c.patch.gz

The issue is not reproducible with this topology.

@abonislawski
Copy link
Member

@syedk008 could you please attach dmesg log with IPC payload data? (for full iteration - aplay - arecord - end)
Our validation will try to reproduce exactly the same scenario on ARL-S without linux driver.

I can confirm it works fine in basic dmic 4ch tests.

@syedk008
Copy link
Author

@syedk008 could you please attach dmesg log with IPC payload data? (for full iteration - aplay - arecord - end) Our validation will try to reproduce exactly the same scenario on ARL-S without linux driver.

I can confirm it works fine in basic dmic 4ch tests.

Attached are the dmesg logs.
dmesg_clean.txt
dmesg_noisy.txt

@singalsu
Copy link
Collaborator

singalsu commented Jun 12, 2024 •
edited
Loading

I did yesterday testing with the ARL-S device. Some observations:

  • Issues happen with both gcc and xcc builds
  • The DSP load seems to impact occurrence, more frequent corruption with higher load topologies. With DMIC capture in passthough but normal HDA playback pipelines the occurrence is low. Also generally the occurrence varies a lot, sometimes many successive runs are corrupt, sometimes it takes even with full topology a lot of runs to see the issue.
  • Switched DCCOMP off in DMIC blob. Also set capture IIR to passthrough with sof-ctl. When corruption happens, the DC level of corrupted signal shifts the noise to fully to positive PCM codes side.
  • Set in DMIC blob FIR coefficients to zero to force decimator output to zero. Then applied with DC channel registers a fixed offset to channels. With these forced DC values I was never able to see corruption, after some 20 runs of Karim's script. Just clean stream of constant PCM code values, except the start gain ramps. But this needs more runs to confirm this configuration never corripts, so not 100% sure about this.

@singalsu singalsu mentioned this issue Jun 14, 2024
Closed
@singalsu
Copy link
Collaborator

Fix proposal: zephyrproject-rtos/zephyr#74414

@kv2019i kv2019i mentioned this issue Jun 20, 2024
Merged
kv2019i added a commit to kv2019i/sof that referenced this issue Jun 20, 2024
@kv2019i
west.yml: update Zephyr to sof/stable-v2.10 0f7a01d360e
15f8115 
Fast-forward the Zephyr version with following backported fixes:

64ee60cf3a6a Drivers: DAI: Intel: Move ACE DMIC start reset clear to earlier
1b78308a6c7c Drivers: DAI: Intel: Reduce traces dai_dmic_start()
995e182b87ab Drivers: DAI: Intel: Remove trace from dai_dmic_update_bits()

Link: thesofproject#9205
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@kv2019i kv2019i mentioned this issue Jun 20, 2024
Merged
kv2019i added a commit that referenced this issue Jun 20, 2024
@kv2019i
west.yml: update Zephyr to sof/stable-v2.10 0f7a01d360e
39f76e4 
Fast-forward the Zephyr version with following backported fixes:

64ee60cf3a6a Drivers: DAI: Intel: Move ACE DMIC start reset clear to earlier
1b78308a6c7c Drivers: DAI: Intel: Reduce traces dai_dmic_start()
995e182b87ab Drivers: DAI: Intel: Remove trace from dai_dmic_update_bits()

Link: #9205
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@lyakh
Copy link
Collaborator

lyakh commented Jun 25, 2024

With zephyrproject-rtos/zephyr#74414 this problem couldn't be reproduced any more so far. Since the noise when it appears with unpatched firmware begins directly at the start of a capture, it makes sense that modifying DMIC initialisation flow fixes the problem.

@kv2019i kv2019i mentioned this issue Jun 25, 2024
Closed
@kv2019i
Copy link
Collaborator

kv2019i commented Jun 28, 2024

Fixed part of release v2.10 (a Zephyr fix so backported directly), removing the tag. Let's close once the Zephyr fix lands in SOF main via west.yml update (i.e. #9258 or similar).

@kv2019i kv2019i removed this from the v2.10 milestone Jun 28, 2024
kv2019i added a commit to kv2019i/sof that referenced this issue Jul 3, 2024
@kv2019i
west.ytml: update to Zephyr 650227d8c47f
7b36d94 
Update Zephyr baseline to 650227d8c47f

Change affecting SOF build targets:

32d05d360b93 intel_adsp/ace: power: fix firmware panic on MTL
a3835041bd36 intel_adsp/ace: power: Use MMU reinit API on core context restore
a983a5e399fd dts: xtensa: intel: Remove non-existent power domains from ACE30 PTL DTS
a2eada74c663 dts: xtensa: intel: Remove ALH nodes from ACE 3.0 PTL DTS
442e697a8ff7 dts: xtensa: intel: Reorder power domains by bit position in ACE30
d1b5d7092e5a intel_adsp: ace30: Correct power control register bitfield definitions
31c96cf3957b xtensa: check stack boundaries during backtrace
5b84bb4f4a55 xtensa: check stack frame pointer before dumping registers
cb9f8b1019f1 xtensa: separate FATAL EXCEPTION printout into two
e9c23274afa2 Revert "soc: intel_adsp: only implement FW_STATUS boot protocol for cavs"
1198c7ec295b Drivers: DAI: Intel: Move ACE DMIC start reset clear to earlier
78920e839e71 Drivers: DAI: Intel: Reduce traces dai_dmic_start()
9db580357bc6 Drivers: DAI: Intel: Remove trace from dai_dmic_update_bits()
f91700e62968 linker: nxp: adsp: add orphan linker section

Link: thesofproject#9268
Link: thesofproject#9243
Link: thesofproject#9205
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@kv2019i kv2019i mentioned this issue Jul 3, 2024
Merged
kv2019i added a commit that referenced this issue Jul 4, 2024
@kv2019i
west.ytml: update to Zephyr 650227d8c47f
d560643 
Update Zephyr baseline to 650227d8c47f

Change affecting SOF build targets:

32d05d360b93 intel_adsp/ace: power: fix firmware panic on MTL
a3835041bd36 intel_adsp/ace: power: Use MMU reinit API on core context restore
a983a5e399fd dts: xtensa: intel: Remove non-existent power domains from ACE30 PTL DTS
a2eada74c663 dts: xtensa: intel: Remove ALH nodes from ACE 3.0 PTL DTS
442e697a8ff7 dts: xtensa: intel: Reorder power domains by bit position in ACE30
d1b5d7092e5a intel_adsp: ace30: Correct power control register bitfield definitions
31c96cf3957b xtensa: check stack boundaries during backtrace
5b84bb4f4a55 xtensa: check stack frame pointer before dumping registers
cb9f8b1019f1 xtensa: separate FATAL EXCEPTION printout into two
e9c23274afa2 Revert "soc: intel_adsp: only implement FW_STATUS boot protocol for cavs"
1198c7ec295b Drivers: DAI: Intel: Move ACE DMIC start reset clear to earlier
78920e839e71 Drivers: DAI: Intel: Reduce traces dai_dmic_start()
9db580357bc6 Drivers: DAI: Intel: Remove trace from dai_dmic_update_bits()
f91700e62968 linker: nxp: adsp: add orphan linker section

Link: #9268
Link: #9243
Link: #9205
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
@kv2019i
Copy link
Collaborator

kv2019i commented Jul 4, 2024

Fix merged via #9278

@kv2019i kv2019i closed this as completed Jul 4, 2024
eddy1021 pushed a commit to eddy1021/sof that referenced this issue Jul 15, 2024
@kv2019i
west.ytml: update to Zephyr 650227d8c47f
c6c69bd 
Update Zephyr baseline to 650227d8c47f

Change affecting SOF build targets:

32d05d360b93 intel_adsp/ace: power: fix firmware panic on MTL
a3835041bd36 intel_adsp/ace: power: Use MMU reinit API on core context restore
a983a5e399fd dts: xtensa: intel: Remove non-existent power domains from ACE30 PTL DTS
a2eada74c663 dts: xtensa: intel: Remove ALH nodes from ACE 3.0 PTL DTS
442e697a8ff7 dts: xtensa: intel: Reorder power domains by bit position in ACE30
d1b5d7092e5a intel_adsp: ace30: Correct power control register bitfield definitions
31c96cf3957b xtensa: check stack boundaries during backtrace
5b84bb4f4a55 xtensa: check stack frame pointer before dumping registers
cb9f8b1019f1 xtensa: separate FATAL EXCEPTION printout into two
e9c23274afa2 Revert "soc: intel_adsp: only implement FW_STATUS boot protocol for cavs"
1198c7ec295b Drivers: DAI: Intel: Move ACE DMIC start reset clear to earlier
78920e839e71 Drivers: DAI: Intel: Reduce traces dai_dmic_start()
9db580357bc6 Drivers: DAI: Intel: Remove trace from dai_dmic_update_bits()
f91700e62968 linker: nxp: adsp: add orphan linker section

Link: thesofproject#9268
Link: thesofproject#9243
Link: thesofproject#9205
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lyakh lyakh

@singalsu singalsu

Labels
bug Something isn't working as expected P1 Blocker bugs or important features production blocker
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@lyakh @lgirdwood @syedk008 @singalsu @abonislawski @kv2019i