Repository navigation
[BUG] Intermittent audio distortion on Dell 9700 / sof-cml-rt711-rt1308-rt715.tplg / firmware 1.6 #3499
Description
Intermittent audio distortion is experienced on firmware 1.6.
Videos of the issue:
the relevant outputs in alsamixer (distortion goes away when muted) are rt1308-1 DAC L and rt1308-1 DAC R - if you're unfamiliar with the hardware, as a reminder, these are both for the left channel despite the name but one seems to be doing a woofer and another a tweeter.
I used 1.5.1 for a long time and never experienced this issue.
To Reproduce
The issue occurs when the pcm stream is first opened and continues until it is closed. Stopping all sound until the stream closes and then starting up again is enough to stop the issue.
Reproduction Rate
I can't see anything in the logs which indicates the issue occurred but I would estimate to be 1/30 or thereabouts. It seems to be more common with notification sounds than, for example, music or a video playing, but I couldn't say for sure, because of course I just have more notifications going off than starting videos like that.
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: thesofproject/linux@96b9d7c
- SOF: built files from https://github.com/thesofproject/sof-bin/tree/stable-v1.6
- Name of the topology file
- Topology:
intel/sof-tplg/sof-cml-rt711-rt1308-rt715.tplg
- Topology:
- Name of the platform(s) on which the bug is observed.
- Platform: Dell 9700 - 0x098F
Screenshots or console output
dmesg and soflog whilst I played a notification sound on repeat roughly 100 times.
soflog-20201006-2126-dmesg.log
soflog-20201006-2126-soflog.log
Audio distortion was heard around the following timestamps
- dmesg 98395.48 / soflog 70109...
- dmesg 98506.40 / soflog 70292...
- dmesg 98606.48 / soflog 70482...
- dmesg 98727.29 / soflog 70711...
- dmesg 98780.62 / soflog 70806..
The rate of occurrence is therefore slightly above 5%.
Activity
plbossart commentedon Oct 6, 2020
@maaarghk you only made references to rt1308-1 and the video seems to hint at a problem on the left speaker. Can you confirm if you hear this distorsion on the right speakers as well?
This is important for us, what happens is that the firmware will push exactly the same content to both amplifiers which are located on separate SoundWire links. rt1308-1 then picks the left channels and rt1308-2 pick the right channel only.
maaarghk commentedon Oct 6, 2020
I can confirm for sure it is on left speaker only.
plbossart commentedon Oct 6, 2020
@maaarghk thanks, this is super-useful information. I will try to cook a patch that ignores the right amplifier completely and uses the 'other' topology for Dell devices, where there is only a single amp. If you still hear the distorsion, it might be your hardware. if you don't then it's likely a problem in the firmware demux functionality.
plbossart commentedon Oct 6, 2020
@maaarghk can you try this patch on top of your kernel:
soundwire-left-amp.diff.txt
This should disable the right amp entirely as well as the demux in the firmware. You will need a different topology (-mono suffix) and a different UCM file will be loaded, but that should be fine if you have the latest stuff installed.
if you can confirm before and after applying the patch the results of amixer -Dhw:0 info that will help check that you've indeed move from 2 amps to one.
Thanks for your patience and help in tracking down this issue.
Edit: to be clearer, the right amp will still be detected but it'll be ignored by SOF. There's no hardware change or any side effect...
maaarghk commentedon Oct 6, 2020
Hi Pierre, I retried the same test of 100 notification sounds with your patch applied. As expected, audio from left speaker only. There was no distortion present.
soflog-20201006-2340-soflog.log
soflog-20201006-2340-dmesg.log
amixer-after-patch.txt
amixer-before-patch.txt
lgirdwood commentedon Oct 7, 2020
@KaiChuan-Hsieh fyi.
plbossart commentedon Oct 7, 2020
@maaarghk thank you for your tests. This rules out a broken speaker or hardware and points to the firmware demux in my opinion. That's really the only difference with the single amp mode, the driver uses the same sequence in single and multi-link cases.
@bardliao @slawblauciak @RanderWang do you concur with my analysis?
juimonen commentedon Oct 7, 2020
@plbossart @maaarghk demux is very likely cause of this (or pipeline setup/timing causing wrong configuration in demux). In that case this won't show up in dmesg, we would need sof firmware logs when distortion occurs, and not sure how verbose it should be to make this visible...
lgirdwood commentedon Oct 7, 2020
@juimonen btw are we able to validate demux routing logic in test bench yet ? Would be good to have such tests in CI
maaarghk commentedon Oct 7, 2020
Hi @juimonen - is the "soflog.log" file I attached not what you need? I am happy to do whatever other traces you need, but might need talked through it in a bit of detail because I have no familiarity with alsa nevermind sof or soundwire.
juimonen commentedon Oct 7, 2020
@maaarghk yeah, sorry I should read more carefully. I'm not sure can we set the firmware debug level to be more verbose, we should see inside the mux_params and others what it is actually setting. I remember these kind of issues happening when for some reason the demux parameter forwarding logic goes wrong, so some audio branch thinks it using 24 bits etc. even though it is not.
maaarghk commentedon Oct 7, 2020
If you want to email me some firmware build with extra debug info feel free.
Edit / or if it's easy to compile with a patch?
24 remaining items
juimonen commentedon Nov 4, 2020
@libinyang thanks! @bardliao if Bard's test is good, @bkokoszx please make a proper PR, this is the right way to fix this.
bardliao commentedon Nov 4, 2020
I tested it and I can't find the distortion with bkokoszx@da1a5cd on my side
bkokoszx commentedon Nov 4, 2020
@lgirdwood
I've performed tests with slim driver with format:
48 kHz, 32/32, 8, on the following topology:And I've got following MCPS value for DEMUX:
plbossart commentedon Nov 4, 2020
What are the units for 1031 and 10787?
bkokoszx commentedon Nov 4, 2020
The units are
plat_ticks/pipeline_periodorcpu_ticks/pipeline_period. In above case (pipeline_period = 1ms):plbossart commentedon Nov 4, 2020
@bkokoszx ~10 MCPS doesn't seem super-optimized for a plain data mover. We handle 48kHz data, that means an average of ~200 cycles per sample frame. DSPs should be able to do better.
It's not the end of the world for now but we will have to use an 8-ch MUX to deal with speaker-protection with I/V feedback and the number will start to be significant. see thesofproject/linux#2514 for more details.
juimonen commentedon Nov 4, 2020
@bkokoszx just for comparison can you provide the figure without your patch with same settings?
bkokoszx commentedon Nov 5, 2020
@juimonen
Do you mean without PR #3583 or without whole simplification in PR #3000 ?
juimonen commentedon Nov 5, 2020
@bkokoszx I meant without #3583. As I understood that @lgirdwood concern was that we are introducing more mips compared to the previous simplification. Or maybe you already have the figures from last simplification?
bkokoszx commentedon Nov 5, 2020
@juimonen
Without #3000 (I've reverted 5bf8188) and without #3586 :
Without #3583 (actual master):
juimonen commentedon Nov 5, 2020
@bkokoszx ok so 1mpcs addition to the previous 9 (9->10)? I think that's ok then...