[bug report] 'ASoC: Intel: haswell: Power transition refactor' and PulseAudio
After upgrading to Linux 5.8 I discovered an audio issue on my device that was introduced in 8ec7d6043263ecf250b9b7c0dd8ade899487538a [0]. I used 'git bisect' to identify the commit that introduced the bug and have confirmed that reverting the commit resolves the problem
Reproduction:
1. Play any audio via PulseAudio. 2. Observe that the audio output is fuzzy and choppy.
I can use programs like mpv to play audio without PulseAudio, and the audio is fine, but as soon as I open a process that uses PulseAudio it will ruin the audio output for all processes (including mpv) until I reboot.
I'm using a 2015 Chromebook Pixel ("Samus") and have confirmed this problem with a friend who has the same device.
Is there anything I can do to help debug this instead of sending a patch to revert the commit?
Relevant lspci output:
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09) Subsystem: Intel Corporation Broadwell-U Audio Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 50 Region 0: Memory at e1218000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00378 Data: 0000 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- FLReset+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel
[0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=8...
On 2020-08-31 11:55 PM, Christian Bundy wrote:
After upgrading to Linux 5.8 I discovered an audio issue on my device that was introduced in 8ec7d6043263ecf250b9b7c0dd8ade899487538a [0]. I used 'git bisect' to identify the commit that introduced the bug and have confirmed that reverting the commit resolves the problem
Reproduction:
- Play any audio via PulseAudio.
- Observe that the audio output is fuzzy and choppy.
I can use programs like mpv to play audio without PulseAudio, and the audio is fine, but as soon as I open a process that uses PulseAudio it will ruin the audio output for all processes (including mpv) until I reboot.
I'm using a 2015 Chromebook Pixel ("Samus") and have confirmed this problem with a friend who has the same device.
Is there anything I can do to help debug this instead of sending a patch to revert the commit?
Hello Christian,
Thank you for report! Issue is a known one to us and has already been addressed by:
[PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html
waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
Basically, once power-cycle (D0 -> D3 -> D0 transition flow) had been fixed, more - previously hidden - problems arisen. Instead of sending 70+ patches to Mark refactoring existing code to recommended flow (+ readability and performance improvements), replacement is provided along with old code being removed entirely.
For now, if there's a possibility for you to modify your kernel, said patch can be safely removed from your local repo. Note: following is the outcome: - DMA init may occasionally fail on early boot (audio card won't be present at all, requires reboot) - D0/D3 flow doesn't follow recommended sequence and thus power-saving may be limited or non-existent Probably still better than permanently fuzzied audio..
I'm sorry for any inconvenience this has caused to you.
Regards, Czarek
On 9/1/20 6:33 AM, Cezary Rojewski wrote:
On 2020-08-31 11:55 PM, Christian Bundy wrote:
After upgrading to Linux 5.8 I discovered an audio issue on my device that was introduced in 8ec7d6043263ecf250b9b7c0dd8ade899487538a [0]. I used 'git bisect' to identify the commit that introduced the bug and have confirmed that reverting the commit resolves the problem
Reproduction:
- Play any audio via PulseAudio.
- Observe that the audio output is fuzzy and choppy.
I can use programs like mpv to play audio without PulseAudio, and the audio is fine, but as soon as I open a process that uses PulseAudio it will ruin the audio output for all processes (including mpv) until I reboot.
I'm using a 2015 Chromebook Pixel ("Samus") and have confirmed this problem with a friend who has the same device.
Is there anything I can do to help debug this instead of sending a patch to revert the commit?
Hello Christian,
Thank you for report! Issue is a known one to us and has already been addressed by:
[PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html
waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
That leaves people with no working sound for 5.8 and 5.9.
Basically, once power-cycle (D0 -> D3 -> D0 transition flow) had been fixed, more - previously hidden - problems arisen. Instead of sending 70+ patches to Mark refactoring existing code to recommended flow (+ readability and performance improvements), replacement is provided along with old code being removed entirely.
For now, if there's a possibility for you to modify your kernel, said patch can be safely removed from your local repo. Note: following is the outcome:
- DMA init may occasionally fail on early boot (audio card won't be
present at all, requires reboot)
- D0/D3 flow doesn't follow recommended sequence and thus power-saving
may be limited or non-existent Probably still better than permanently fuzzied audio..
Doesn't this mean that a revert is needed and applied to -stable for 5.8 and 5.9?
On 2020-09-01 3:38 PM, Pierre-Louis Bossart wrote:
On 9/1/20 6:33 AM, Cezary Rojewski wrote:
...
Hello Christian,
Thank you for report! Issue is a known one to us and has already been addressed by:
[PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html
waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
That leaves people with no working sound for 5.8 and 5.9.
Basically, once power-cycle (D0 -> D3 -> D0 transition flow) had been fixed, more - previously hidden - problems arisen. Instead of sending 70+ patches to Mark refactoring existing code to recommended flow (+ readability and performance improvements), replacement is provided along with old code being removed entirely.
For now, if there's a possibility for you to modify your kernel, said patch can be safely removed from your local repo. Note: following is the outcome:
- DMA init may occasionally fail on early boot (audio card won't be
present at all, requires reboot)
- D0/D3 flow doesn't follow recommended sequence and thus power-saving
may be limited or non-existent Probably still better than permanently fuzzied audio..
Doesn't this mean that a revert is needed and applied to -stable for 5.8 and 5.9?
I believe you're right Pierre, revert should be provided. I'll see to it.
Czarek
On Tue, 2020-09-01 at 13:33 +0200, Cezary Rojewski wrote:
On 2020-08-31 11:55 PM, Christian Bundy wrote:
After upgrading to Linux 5.8 I discovered an audio issue on my device that was introduced in 8ec7d6043263ecf250b9b7c0dd8ade899487538a [0]. I used 'git bisect' to identify the commit that introduced the bug and have confirmed that reverting the commit resolves the problem
Reproduction:
- Play any audio via PulseAudio.
- Observe that the audio output is fuzzy and choppy.
I can use programs like mpv to play audio without PulseAudio, and the audio is fine, but as soon as I open a process that uses PulseAudio it will ruin the audio output for all processes (including mpv) until I reboot.
I'm using a 2015 Chromebook Pixel ("Samus") and have confirmed this problem with a friend who has the same device.
Is there anything I can do to help debug this instead of sending a patch to revert the commit?
Hello Christian,
Thank you for report! Issue is a known one to us and has already been addressed by:
[PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html
waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
Please also don't forget that the new BDW HW register programming flows need to be shared as common code with the SOF BDW driver.
Thanks
Liam
On 2020-09-01 5:23 PM, Liam Girdwood wrote:
On Tue, 2020-09-01 at 13:33 +0200, Cezary Rojewski wrote:
...
Hello Christian,
Thank you for report! Issue is a known one to us and has already been addressed by:
[PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html
waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
Please also don't forget that the new BDW HW register programming flows need to be shared as common code with the SOF BDW driver.
Thanks
Liam
I don't believe this is related to Christian's report.
Anyway, revert-patch for sound/soc/intel/haswell/ solution has been provided so it can be later propagated to v5.8 and v5.9 -stable with matching upstream commit's sha-id.
Czarek
Thanks for the quick response. This is great. I've tested the patch and confirmed that it works.
On Tue, Sep 1, 2020, at 08:37, Cezary Rojewski wrote:
On 2020-09-01 5:23 PM, Liam Girdwood wrote:
On Tue, 2020-09-01 at 13:33 +0200, Cezary Rojewski wrote:
...
Hello Christian,
Thank you for report! Issue is a known one to us and has already been addressed by:
[PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html
waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
Please also don't forget that the new BDW HW register programming flows need to be shared as common code with the SOF BDW driver.
Thanks
Liam
I don't believe this is related to Christian's report.
Anyway, revert-patch for sound/soc/intel/haswell/ solution has been provided so it can be later propagated to v5.8 and v5.9 -stable with matching upstream commit's sha-id.
Czarek
On Tue, 2020-09-01 at 17:37 +0200, Cezary Rojewski wrote:
Thank you for report! Issue is a known one to us and has already been addressed by: [PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg113762.html waiting for final dependency to be merged (Andy's resource-API changes, as Mark already added the SPI ones) so v5 with review changes can be provided. Shouldn't be long before this gets merged. As consequence, /haswell/ ceases to exist.
Please also don't forget that the new BDW HW register programming flows need to be shared as common code with the SOF BDW driver. Thanks Liam
I don't believe this is related to Christian's report.
To be clear, it's related to v5 readiness statement and not this report.
Thanks
Liam
participants (4)
-
Cezary Rojewski -
Christian Bundy -
Liam Girdwood -
Pierre-Louis Bossart