[alsa-devel] Internal speakers not working on HP ProBook 455 G2
Hi,
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
In pavucontrol, the speakers appear as "Speakers (unavailable)", and in the GNOME sound settings they don't appear at all.
After some playing around with HDAAnalyzer, I discovered that enabling the 'OUT' widget control of pin 0x14 makes the speakers emit sound, see the diff below.
Let me know if you need any more information, and I'll happily test any patches to fix this problem.
Diff for codec 1/0 (0x10ec0282): --- +++ @@ -120,39 +120,40 @@ bits [0xe]: 16 20 24 formats [0x1]: PCM Power: setting=D0, actual=D0 Connection: 1 0x12 Node 0x12 [Pin Complex] wcaps 0x40040b: Stereo Amp-In Control: name="Internal Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=1, idx=0, ofs=0 - Control: name="Internal Mic Phantom Jack", index=0, device=0 + Control: iface="card", name="Internal Mic Phantom Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00000020: IN Pin Default 0x90a60140: [Fixed] Mic at Int N/A Conn = Digital, Color = Unknown DefAssociation = 0x4, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Power: setting=D0, actual=D0 Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=1, idx=0, ofs=0 - Control: name="Speaker Phantom Jack", index=0, device=0 + Control: iface="card", name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00010014: OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE + Pin-ctls: 0x40: OUT Unsolicited: tag=0x00, enabled=0 Power: setting=D0, actual=D0 Connection: 1 0x0c Node 0x15 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x16 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x17 [Pin Complex] wcaps 0x40050c: Mono Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote:
Hi,
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
Is this a regression from earlier kernels?
In pavucontrol, the speakers appear as "Speakers (unavailable)", and in the GNOME sound settings they don't appear at all.
After some playing around with HDAAnalyzer, I discovered that enabling the 'OUT' widget control of pin 0x14 makes the speakers emit sound, see the diff below.
Interesting. This behavior doesn't appear on the emulator, so something else must have cleared the pin ctl.
To be sure, load snd-hda-intel module with probe_only=1,1 option. You can check /proc/asound/card1/codec#0 to see which value is set to the pin 0x14 by BIOS as default. Then, enable the tracing via # echo 1 > /sys/kernel/debug/tracing/events/hda/enable
and configure the codec via # echo 1 > /sys/class/sound/hwC1D0/reconfigure
This will set up the PCM and the mixer. Get the events from /sys/kernel/debug/tracing/trace. At this point. Then check again whether pin 0x14 is set or not.
Better to check the above without PulseAudio, i.e. do it in runlevel 3 on Linux console.
Once when the problem is confirmed (the pin control is still 0x00), try to check the events log you got. The bits 28-32 of the event value indicates the codec address, the bits 20-28 the widget nid, and the rest 20 bits the combo of verb + parameter. So, the command SET_PIN_WIDGET_CONTROL for the widget 0x14 should appear like 0x01470740 where 0x707 is SET_PIN_WIDGET_CONTROL verb and 0x40 is the pin control value.
thanks,
Takashi
Takashi-san,
On 19.02.2015 20:38, Takashi Iwai wrote:
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote:
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
Is this a regression from earlier kernels?
No, it's the same with Debian's default 3.16 kernel.
In pavucontrol, the speakers appear as "Speakers (unavailable)", and in the GNOME sound settings they don't appear at all.
In the meantime, I've noticed that those symptoms are due to the headphone jack being incorrectly detected as connected. And indeed, on a different laptop I get all the same symptoms while headphones are plugged in.
So, it occurred to me to try 'the other OS' on this laptop, and the behaviour there is weird as well: No sound from the speakers even while nothing's plugged into the headphone jack. When I plug in headphones, there's a notification: "Something was just unplugged from your headphone jack" (!), then sound works as expected through the headphones. When I unplug them again, there's a notification: "Something was just plugged into your headphone jack".
In Linux, I haven't seen any visible change when plugging in or out the headphones.
Do you think the hardware is defective? Any possible workarounds for the incorrect headphone jack detection?
At Tue, 24 Feb 2015 17:43:10 +0900, Michel D4nzer wrote:
Takashi-san,
On 19.02.2015 20:38, Takashi Iwai wrote:
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote:
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
Is this a regression from earlier kernels?
No, it's the same with Debian's default 3.16 kernel.
What about even older one?
In pavucontrol, the speakers appear as "Speakers (unavailable)", and in the GNOME sound settings they don't appear at all.
In the meantime, I've noticed that those symptoms are due to the headphone jack being incorrectly detected as connected. And indeed, on a different laptop I get all the same symptoms while headphones are plugged in.
So, it occurred to me to try 'the other OS' on this laptop, and the behaviour there is weird as well: No sound from the speakers even while nothing's plugged into the headphone jack. When I plug in headphones, there's a notification: "Something was just unplugged from your headphone jack" (!), then sound works as expected through the headphones. When I unplug them again, there's a notification: "Something was just plugged into your headphone jack".
So the plug state is inverted?
In Linux, I haven't seen any visible change when plugging in or out the headphones.
You can watch the output of "alsactl monitor".
Do you think the hardware is defective? Any possible workarounds for the incorrect headphone jack detection?
The question is whether it's an unreliable jack detection (sometimes / always doesn't report the event) or the jack detection is inverted by some reason (plug / unplug swapped). In the latter case, you can set a hint "inv_jack_detect = 1". See Documentation/sound/alsa/HD-Audio.txt, the section "Hint Strings", "HD-Audio Reconfiguration" and "Early Patching" sections.
Takashi
On 24.02.2015 18:05, Takashi Iwai wrote:
At Tue, 24 Feb 2015 17:43:10 +0900, Michel D4nzer wrote:
On 19.02.2015 20:38, Takashi Iwai wrote:
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote:
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
Is this a regression from earlier kernels?
No, it's the same with Debian's default 3.16 kernel.
What about even older one?
Are you thinking of any particular version(s)? How important is it to test that?
In pavucontrol, the speakers appear as "Speakers (unavailable)", and in the GNOME sound settings they don't appear at all.
In the meantime, I've noticed that those symptoms are due to the headphone jack being incorrectly detected as connected. And indeed, on a different laptop I get all the same symptoms while headphones are plugged in.
So, it occurred to me to try 'the other OS' on this laptop, and the behaviour there is weird as well: No sound from the speakers even while nothing's plugged into the headphone jack. When I plug in headphones, there's a notification: "Something was just unplugged from your headphone jack" (!), then sound works as expected through the headphones. When I unplug them again, there's a notification: "Something was just plugged into your headphone jack".
So the plug state is inverted?
Not exactly. The notifications in Windows sound like that, but the speakers don't work regardless of whether headphones are plugged in or not (even in Windows).
In Linux, I haven't seen any visible change when plugging in or out the headphones.
You can watch the output of "alsactl monitor".
When plugging in headphones:
card 1, #38 (0,0,0,Mic Jack,0) VALUE card 1, #34 (2,0,0,Internal Mic Boost Volume,0) VALUE card 1, #34 (2,0,0,Internal Mic Boost Volume,0) VALUE card 1, #33 (2,0,0,Mic Boost Volume,0) VALUE card 1, #33 (2,0,0,Mic Boost Volume,0) VALUE
When unplugging them again:
card 1, #38 (0,0,0,Mic Jack,0) VALUE card 1, #33 (2,0,0,Mic Boost Volume,0) VALUE card 1, #33 (2,0,0,Mic Boost Volume,0) VALUE card 1, #34 (2,0,0,Internal Mic Boost Volume,0) VALUE card 1, #34 (2,0,0,Internal Mic Boost Volume,0) VALUE
Do you think the hardware is defective? Any possible workarounds for the incorrect headphone jack detection?
The question is whether it's an unreliable jack detection (sometimes / always doesn't report the event) or the jack detection is inverted by some reason (plug / unplug swapped). In the latter case, you can set a hint "inv_jack_detect = 1". See Documentation/sound/alsa/HD-Audio.txt, the section "Hint Strings", "HD-Audio Reconfiguration" and "Early Patching" sections.
Setting inv_jack_detect = 1 makes the speakers work by default, but then plugging in headphones isn't detected.
At Sat, 28 Feb 2015 15:03:41 +0900, Michel D4nzer wrote:
On 24.02.2015 18:05, Takashi Iwai wrote:
At Tue, 24 Feb 2015 17:43:10 +0900, Michel D4nzer wrote:
On 19.02.2015 20:38, Takashi Iwai wrote:
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote:
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
Is this a regression from earlier kernels?
No, it's the same with Debian's default 3.16 kernel.
What about even older one?
Are you thinking of any particular version(s)? How important is it to test that?
No particular version, I just wonder whether this is a regression at all. But the cause is now clear.
In Linux, I haven't seen any visible change when plugging in or out the headphones.
You can watch the output of "alsactl monitor".
When plugging in headphones:
card 1, #38 (0,0,0,Mic Jack,0) VALUE
So, your headphone is recognized wrongly as a microphone. This implies that the pins aren't properly set up by BIOS. Maybe BIOS update will solve this?
If no BIOS update doesn't solve (or you don't want it), you have to figure out the right pin configuration by trial and error. hdajackretask and hda-analyzer would be your friend. (Note that the onboard analog audio is the second card in your case.)
Takashi
On 28.02.2015 16:58, Takashi Iwai wrote:
At Sat, 28 Feb 2015 15:03:41 +0900, Michel D4nzer wrote:
On 24.02.2015 18:05, Takashi Iwai wrote:
At Tue, 24 Feb 2015 17:43:10 +0900, Michel D4nzer wrote:
On 19.02.2015 20:38, Takashi Iwai wrote:
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote:
the built-in speakers of my HP ProBook 455 G2 are not working by default. I'm attaching the output of alsa-info.sh.
[...]
In Linux, I haven't seen any visible change when plugging in or out the headphones.
You can watch the output of "alsactl monitor".
When plugging in headphones:
card 1, #38 (0,0,0,Mic Jack,0) VALUE
So, your headphone is recognized wrongly as a microphone.
Actually, there are two pins for the (black) headphone jack, which BTW has a headset icon next to it. Maybe some kind of headset quirk is needed, or maybe one of the jacks should be gated by the other one?
This implies that the pins aren't properly set up by BIOS. Maybe BIOS update will solve this?
If no BIOS update doesn't solve (or you don't want it),
I already have the latest BIOS version.
you have to figure out the right pin configuration by trial and error. hdajackretask and hda-analyzer would be your friend.
I've been playing around with them, but I don't really know what I'm doing, and I haven't had much luck yet.
Something else I've noticed in the meantime: With inv_jack_detect enabled, I can get sound from the speakers by choosing them for output in the GNOME sound preferences. If I choose "Analog Output - Built-in Audio" there, the sound comes out of the connected headphones.
At Tue, 24 Mar 2015 17:09:00 +0900, Michel D4nzer wrote:
On 28.02.2015 16:58, Takashi Iwai wrote:
At Sat, 28 Feb 2015 15:03:41 +0900, Michel D4nzer wrote:
On 24.02.2015 18:05, Takashi Iwai wrote:
At Tue, 24 Feb 2015 17:43:10 +0900, Michel D4nzer wrote:
On 19.02.2015 20:38, Takashi Iwai wrote:
At Thu, 19 Feb 2015 15:24:15 +0900, Michel D4nzer wrote: > > the built-in speakers of my HP ProBook 455 G2 are not working by > default. I'm attaching the output of alsa-info.sh.
[...]
In Linux, I haven't seen any visible change when plugging in or out the headphones.
You can watch the output of "alsactl monitor".
When plugging in headphones:
card 1, #38 (0,0,0,Mic Jack,0) VALUE
So, your headphone is recognized wrongly as a microphone.
Actually, there are two pins for the (black) headphone jack, which BTW has a headset icon next to it. Maybe some kind of headset quirk is needed, or maybe one of the jacks should be gated by the other one?
For a headset support, yes, some extra quirk would be needed. But usually the headset pin is assigned as the headphone primarily. If you don't get the headphone jack detect event, it means that the headphone pin isn't properly assigned.
This implies that the pins aren't properly set up by BIOS. Maybe BIOS update will solve this?
If no BIOS update doesn't solve (or you don't want it),
I already have the latest BIOS version.
you have to figure out the right pin configuration by trial and error. hdajackretask and hda-analyzer would be your friend.
I've been playing around with them, but I don't really know what I'm doing, and I haven't had much luck yet.
Basically you need to figure out which pin corresponds to the headphone jack. You can do it even without GUI. For example, to check whether the pin widget 0x0a:
hda-verb /dev/snd/hwC0D0 0x0a SET_PIN_SENSE 0 hda-verb /dev/snd/hwC0D0 0x0a GET_PIN_SENSE 0
The first triggers the jack detection and the second reads the detected value. If the jack is detected on that pin, you'll see the bit 31 on. Repeat this for all widgets until you hit.
(In the above I assume the codec chip is in the card 0, codec address 0. If it's different, use another corresponding hwdep device.)
Something else I've noticed in the meantime: With inv_jack_detect enabled, I can get sound from the speakers by choosing them for output in the GNOME sound preferences. If I choose "Analog Output - Built-in Audio" there, the sound comes out of the connected headphones.
inv_jack_detect is most likely wrong for new machines. It's only for some old machines with the wrong h/w implementation. I've never seen this for the recent machines.
That said, the reason inv_jack_detect makes speaker working is that the headphone jack is wrongly detected as if constantly plugged. Then with the inverted logic, it's regarded as constantly unplugged, so the speaker gets unmuted.
HTH,
Takashi
On 24.02.2015 17:43, Michel Dänzer wrote:
In the meantime, I've noticed that those symptoms are due to the headphone jack being incorrectly detected as connected. And indeed, on a different laptop I get all the same symptoms while headphones are plugged in.
So, it occurred to me to try 'the other OS' on this laptop, and the behaviour there is weird as well: No sound from the speakers even while nothing's plugged into the headphone jack. When I plug in headphones, there's a notification: "Something was just unplugged from your headphone jack" (!), then sound works as expected through the headphones. When I unplug them again, there's a notification: "Something was just plugged into your headphone jack".
Since this was happening in the pre-installed Windows as well, I finally convinced myself that this couldn't be (purely) a software issue and contacted HP support. Thankfully I bought extended warranty including on-site support, so today a technician came, and after he exchanged the audio board, everything's working as expected out of the box in both OSs. Thanks to everyone who made that possible in Linux, and especially to you Takashi-san for trying to help me with this problem, which turned out to be unsolvable in software.
participants (2)
-
Michel Dänzer -
Takashi Iwai