On Thu, 02 Jun 2016 23:20:24 +0200, Laura Abbott wrote:
On 05/24/2016 10:54 AM, Takashi Iwai wrote:
On Tue, 24 May 2016 18:41:06 +0200, Laura Abbott wrote:
Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x42, nsteps=0x42, stepsize=0x03, mute=1 Amp-Out vals: [0x42 0x42] Pincap 0x0000001c: OUT HP Detect Pin Default 0x002b4020: [Jack] HP Out at Ext N/A Conn = Comb, Color = Green DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D3 EPSS Power: setting=D3, actual=D3
This pin is powered off, because...
control.18 { iface CARD name 'Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.19 { iface CARD name 'Line Out Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.20 { iface CARD name 'Headphone Jack' value false
The headphone jack isn't detected. Meanwhile,
control.22 { iface CARD name 'SPDIF Jack' value true
SPDIF jack is detected. This might confuse PA.
In anyway, the alsa-info.sh output you gave doesn't help for analyzing the issue while the headphone is plugged. It is off when unplugged. It's the designed behavior.
So, please give the information during the headphone is plugged (but still doesn't produce the sound from the headphone).
Takashi
According to the reporter:
"Actually, that information was when the headphones were plugged in, but the detection is incorrect. (Linux thinks the headphones are unplugged, when they are actually plugged in."
It implies that the pin setup mismatches with the actual hardware. You need to figure out which pin corresponds to the actual I/O by yourself, e.g. via hdajackretask or other tool.
The apparent regression just revealed the already buggy setup.
Takashi