[BUG] [Regression] Intel hda-dai doesn't recover gracefully from underruns; audio distortion #4455
Comments
|
Thanks for the report @CFSworks, that's indeed a nasty issue. It's probably an issue with the xrun flow, where we restart with a .prepare step first. This is different to the regular stop/start sequence that the commit 05cbb39 meant to fix. Can you please attach the log of 'alsa-info'? If you can, please add this file @ranj063 @kv2019i @lgirdwood FYI. |
Located here.
Not applicable in my case since all of the ALSA modules are compiled builtin. I can reboot my kernel with some |
|
Thanks @CFSworks I don't see anything suspicious or bad in the alsa-info log. We would indeed need more information with the command line options. One note: we don't really support the builtin mode, there are known issues with the firmware not being available on the file system, all known users prefer modules. |
Annotated dmesg output of dyndbg trace |
|
Hello, I'm here to comment that i have the exact same problem under my PC, however i don't use I'm able to reproduce this using the command provided by @CFSworks Here i attach a video with the audio artifacts occurring when I use the command 2023-07-20.01-58-44.mp4
If I'm wrong and my bug is not related with this one, please tell me. Thanks |
|
I don't think it is related; it sounds like you're having underruns (which ARE irritating) but the audio output recovers after each time the underrun happens. This issue was opened because the audio output does NOT recover for me: it begins dropping (zeroing) samples which results in a grating distortion that's present even between the underruns. I would recommend disabling Pipewire and trying some audio tests against the raw ALSA audio output device. If the underruns go away or are at least much less frequent, yours is probably an issue to report to the Pipewire project. |
|
I did a potentially duplicated new bug at #4482 The comments in https://bugzilla.kernel.org/show_bug.cgi?id=217673 indicate a bisect point to patch described in #4482 (comment) |
|
@ranj063 The patch doesn't apply as-is against 6.4 but I was able to get it to build by adding back the In the first few minutes, I tried inducing numerous underruns and the distortion hasn't happened yet, so it does seem to have resolved the problem. I will keep running on this patch and report back if the distortion happens again. Thanks! |
|
@CFSworks I have updated the PR now. Could you please help check if it applies agsint 6.4 now? |
ranj063
added a commit
to ranj063/linux
that referenced
this issue
Jul 24, 2023
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: thesofproject#4455 Closes: thesofproject#4482 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
It still does not; the 6.4 version of However, I've been alternating between booting my kernel with the patch applied vs. not applied and the audio distortion only occurs on the unpatched kernel, so I am confident that the PR does resolve the problem. |
Thanks for checking @CFSworks |
|
As reported on the openSUSE Bugzilla, a version of the patch adapted for 6.4.x kernels solved the issue for me. |
plbossart
pushed a commit
that referenced
this issue
Jul 31, 2023
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: #4455 Closes: #4482 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
plbossart
pushed a commit
that referenced
this issue
Aug 2, 2023
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: #4455 Closes: #4482 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
plbossart
pushed a commit
that referenced
this issue
Aug 7, 2023
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: #4455 Closes: #4482 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
plbossart
pushed a commit
that referenced
this issue
Aug 7, 2023
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: #4455 Closes: #4482 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
plbossart
pushed a commit
to plbossart/sound
that referenced
this issue
Aug 8, 2023
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: thesofproject#4455 Closes: thesofproject#4482 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217673 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230808110627.32375-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Whissi
pushed a commit
to Whissi/linux-stable
that referenced
this issue
Aug 23, 2023
commit 90219f1 upstream. With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: thesofproject/linux#4455 Closes: thesofproject/linux#4482 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217673 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230808110627.32375-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Commit 05cbb39 introduced a regression.
Sometimes (often, but not every time), when an underrun occurs while playing audio through some HDA-DAI codec, the audio output will begin distorting the audio. Playing a 440 Hz test tone results in a spectrum of 440 Hz, 560 Hz, 1440 Hz, 1560 Hz, ..., which is consistent with the output being modulated by a 1000 Hz Dirac comb -- e.g. one sample being dropped every 1ms.
This can be reproduced on (at least) TGL:
speaker-test -D 'hw:1,0' -r 48000 -c 2 -f 440 -F S16_LE -b 1000 -t sinekillall -STOP speaker-test; killall -CONT speaker-testThe text was updated successfully, but these errors were encountered: