[Realtek ALC892, Green Headphone Out, Front] Not detecting/switching to front jack after plugging in headphones

[Francis Chin]

I boot my system without any sound devices plugged into any jacks; checking Gnome settings Sound, Output Device is "Dummy Output" (no other options available in drop-down list). I plug in headphones into the front jack and play some audio, but do not hear any sound from the headphones; checking Gnome settings Sound, the Output Device is still "Dummy Output", with no other options available.

This is a regression from previous behaviour, when plugging in headphones into the front jack would automatically enable/switch to the front jack and its associated controller "Family 17h (Models 00h-0fh) HD Audio Controller" (this is the motherboard's onboard audio hardware).

I can currently workaround this each time I plug in the headphones by installing and running pavucontrol, and under Configuration selecting "Analogue Stereo Output (unplugged) (unavailable)" - this option becomes "Analogue Stereo Output" after I select it.

This seems to be a regression in pulseaudio after an upgrade from from 1:13.99.1-1ubuntu3.3 to 1:13.99.1-1ubuntu3.5.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: chinf 1741 F.... pulseaudio
 /dev/snd/pcmC1D0p: chinf 1741 F...m pulseaudio
 /dev/snd/controlC0: chinf 1741 F.... pulseaudio
 /dev/snd/timer: chinf 1741 f.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun Jul 26 12:46:52 2020
InstallationDate: Installed on 2018-10-29 (635 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic successful
Symptom_Card: Family 17h (Models 00h-0fh) HD Audio Controller - HD-Audio Generic
Symptom_DevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: chinf 1741 F.... pulseaudio
 /dev/snd/controlC0: chinf 1741 F.... pulseaudio
Symptom_Jack: Green Headphone Out, Front
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: No sound at all
Title: [To Be Filled By O.E.M., Realtek ALC892, Green Headphone Out, Front] No sound at all
UpgradeStatus: Upgraded to focal on 2020-05-04 (83 days ago)
dmi.bios.date: 12/19/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P5.40
dmi.board.name: AB350 Pro4
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP5.40:bd12/19/2018:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnAB350Pro4:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: To Be Filled By O.E.M.
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

[Hui Wang (hui.wang)]

After you plug in the headphone, the Active Profile should change to be <output:analog-stereo>

Could you please redo the test and upload a log?
reboot with headphone unplugged,
after booting up, plug headphone, make sure the headphone couldn't output sound,
run 'pacmd list > pa.log', then upload the pa.log.

thx.

[Francis Chin (chinf)]

As requested - after a fresh boot, and plugging in headphones and verifying that there is no sound from them.

[Francis Chin (chinf)]

For comparison, a log from before I plug in the headphones (after a fresh boot)

[Francis Chin (chinf)]

And a log from after I use pavucontrol to manually enable the 17h audio controller while the headphones are plugged in, and confirming that they do work as they used to.

[Hui Wang (hui.wang)]

After you plug in the headphone, the headphone jack should change to available yes, but according to the log in the #3, it is still available no:

  analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, available: no)
   properties:
    device.icon_name = "audio-headphones"

That is the reason the audio didn't auto switch. Looks like this is a kernel driver issue.

please do a test:

plug in the headphone, and the headphone can't output sound, then run 'alsa-info.sh to generate alsa-info.txt and run cat /proc/asound/card1/codec#0", now please check if headphone could work now? and upload the alsa-info.txt and the log of 'pacmd list'.

thx.

[Francis Chin (chinf)]

For reference, after a fresh boot without headphones plugged in on my machine, the alsa-info command gives the attached output.

[Francis Chin (chinf)]

Then after the fresh boot, I connected the headphones, verified no sound, then re-ran alsa-info which gave the following attached log.

[Francis Chin (chinf)]

After running alsa-info, it appears that the headphones were detected and started to show in Settings GUI, also showing in the attached pacmd list report.

[Francis Chin (chinf)]

The output of cat /proc/asound/card1/codec#0 after running alsa-info differs slightly to that included within the alsa-info log itself (in #8):

26c335
< Converter: stream=0, channel=0
---
> Converter: stream=5, channel=0
38c347
< Converter: stream=0, channel=0
---
> Converter: stream=5, channel=0
52c361
< Converter: stream=0, channel=0
---
> Converter: stream=5, channel=0
64c373
< Converter: stream=0, channel=0
---
> Converter: stream=5, channel=0

[Francis Chin (chinf)]

To add to #9, as well as the headphones being detected after running alsa-info, I can confirm that they still work as expected after detection.

As this may be a bug introduced by a kernel change, the current kernel running is 5.4.0.42.45 (generic, x86_64), whereas the previous one I was running when I didn't see this bug was 5.4.0.40.43.

[Hui Wang (hui.wang)]

So this is a kernel driver issue instead of pulseaudio issue. It has sth to do with power management, and it is difficult to debug this kind of issue without a physical machine.

you could use a workaround like snd_hda_intel.power_save=0 or snd_hda_intel.power_save=,0 I don't whchi one is correct workaround, please test them and choose one of them.

[Francis Chin (chinf)]

Ignore my last comment about last known working kernel, I've rebooted to 5.4.0.40 and I still see this issue, will try and do more testing on kernel versions to see if I can find where it changes, and will also look into the power_save options.

[Francis Chin (chinf)]

Last known working kernel: 5.4.0-33, next installable Ubuntu kernel 5.4.0-37 introduces the bug.

I have tested that saving "options snd_hda_intel power_save=0" to a file under /etc/modprobe.d and rebooting to a kernel from -37 onwards is a valid workaround.

Lines mentioning ALSA from http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_5.4.0-37.41/changelog:

  * Focal update: v5.4.40 upstream stable release (LP: #1878040)
    - ALSA: hda: Match both PCI ID and SSID for driver blacklist

  * Focal update: v5.4.39 upstream stable release (LP: #1877592)
    - ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
    - ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
    - ALSA: hda/hdmi: fix without unlocked before return
    - ALSA: line6: Fix POD HD500 audio playback
    - ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
    - ALSA: opti9xx: shut up gcc-10 range warning

  * Focal update: v5.4.37 upstream stable release (LP: #1876765)
    - ALSA: hda: Release resources at error in delayed probe
    - ALSA: hda: Keep the controller initialization even if no codecs found
    - ALSA: hda: Explicitly permit using autosuspend if runtime PM is supported
    - ALSA: hda: call runtime_allow() for all hda controllers

  * Focal update: v5.4.36 upstream stable release (LP: #1876361)
    - ALSA: usb-audio: Add Pioneer DJ DJM-250MK2 quirk
    - ALSA: hda: Remove ASUS ROG Zenith from the blacklist
    - ALSA: usb-audio: Add static mapping table for ALC1220-VB-based mobos
    - ALSA: usb-audio: Add connector notifier delegation
    - ALSA: usx2y: Fix potential NULL dereference
    - ALSA: hda/realtek - Fix unexpected init_amp override
    - ALSA: hda/realtek - Add new codec supported for ALC245
    - ALSA: hda/hdmi: Add module option to disable audio component binding
    - ALSA: usb-audio: Fix usb audio refcnt leak when getting spdif
    - ALSA: usb-audio: Filter out unsupported sample rates on Focusrite devices

  * Focal update: v5.4.35 upstream stable release (LP: #1875660)
    - ALSA: hda: Honor PM disablement in PM freeze and thaw_noirq ops
    - ALSA: hda: Don't release card at firmware loading error

  * Support DMIC micmute LED on HP platforms (LP: #1876859)
    - ALSA: hda/realtek - Introduce polarity for micmute LED GPIO
    - ALSA: hda/realtek - Enable micmute LED on and HP system
    - ALSA: hda/realtek - Add LED class support for micmute LED
    - ALSA: hda/realtek - Fix unused variable warning w/o
      CONFIG_LEDS_TRIGGER_AUDIO

  * alsa/sof: kernel oops on the machine without Intel hdmi audio codec (a
    regression in the asoc machine driver) (LP: #1874359)
    - SAUCE: ASoC: intel/skl/hda - fix oops on systems without i915 audio codec

[Hui Wang (hui.wang)]

If you don't use "options snd_hda_intel power_save=0", instead you use "options snd_hda_intel power_save_controller=0", is it a valid workaround too?

[Hui Wang (hui.wang)]

Please test this kernel: https://people.canonical.com/~hwang4/testdetect/

[Francis Chin (chinf)]

Thank you for following up.

I have managed to complete a commit bisect of the Ubuntu kernels and can confirm that the first bad commit is 851cc40f47677174527a1decbd1074feacd15a93:

ALSA: hda: call runtime_allow() for all hda controllers

    BugLink: https://bugs.launchpad.net/bugs/1876765

    [ Upstream commit 9a6418487b566503c772cb6e7d3d44e652b019b0 ]

Regarding #15: I have tested and can confirm that "options snd_hda_intel power_save_controller=0" is also a valid workaround.

Regarding #16: I have reverted the workarounds, booted the test kernel and can confirm that this also fixes my detection problem.

[Hui Wang (hui.wang)]

I reverted that commit in the kernel of #16. So let me think about how to fix it.

thx.

[Hui Wang (hui.wang)]

The patch of #17 is reverted from upstream, and the patch is cced to stable, it will be in the ubuntu kernel sooner or later.

thx.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1888992

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Kai-Heng Feng (kaihengfeng)]

Can you please test the following kernel, which re-enables runtime PM on-top of a proper fix:
https://people.canonical.com/~khfeng/lp1888992/

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Francis Chin (chinf)]

Apologies, I was unable to access the machine for testing this until recently, so have been unable to run the test kernel in #21.

Revisiting this problem again on the same machine with kernel 5.13.0-27 I still see it as behaving as originally reported, so I expect neither the patch nor proper fix has made its way to the ubuntu kernel.