[alsa-devel] [REGRESSION] Headphones no longer working on MacPro6, 1 with 4.4
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
Thanks, Laura
On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote:
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
The obvious difference is the power state of each node. The recent kernel has the finer power saving mode, and this might be the cause -- Mac has some secret that requires some node to be powered up.
Try to power on each node via hda-verb. For example, to power up the node 0x05, run like: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
And check whether it makes any difference. Similarly, try for nodes 0x06, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0f, 0x10, 0x11, 0x14, 0x15, 0x16, 0x17, 0x18.
thanks,
Takashi
On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote:
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
The obvious difference is the power state of each node. The recent kernel has the finer power saving mode, and this might be the cause -- Mac has some secret that requires some node to be powered up.
Try to power on each node via hda-verb. For example, to power up the node 0x05, run like: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
Oops, a typo: the last argument must be 0x00, corresponding to D0: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x00
Takashi
On 03/15/2016 12:49 PM, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote:
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
The obvious difference is the power state of each node. The recent kernel has the finer power saving mode, and this might be the cause -- Mac has some secret that requires some node to be powered up.
Try to power on each node via hda-verb. For example, to power up the node 0x05, run like: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
Oops, a typo: the last argument must be 0x00, corresponding to D0: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x00
Bringing this back again, the command that makes it work is
hda-verb /dev/snd/hwC0D0 0x10 SET_POWER 0x00
And this is still needed as of 4.5.4
Takashi
Thanks, Laura
On Sat, 21 May 2016 00:27:22 +0200, Laura Abbott wrote:
On 03/15/2016 12:49 PM, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote:
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
The obvious difference is the power state of each node. The recent kernel has the finer power saving mode, and this might be the cause -- Mac has some secret that requires some node to be powered up.
Try to power on each node via hda-verb. For example, to power up the node 0x05, run like: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
Oops, a typo: the last argument must be 0x00, corresponding to D0: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x00
Bringing this back again, the command that makes it work is
hda-verb /dev/snd/hwC0D0 0x10 SET_POWER 0x00
OK, then please give alsa-info.sh output (run with --no-upload option) at both working and non-working cases.
And this is still needed as of 4.5.4
Of course, nothing has changed. I didn't hear from you since my previous question...
I'll start checking this later in in the next week.
thanks,
Takashi
On Sat, 21 May 2016 08:41:28 +0200, Takashi Iwai wrote:
On Sat, 21 May 2016 00:27:22 +0200, Laura Abbott wrote:
On 03/15/2016 12:49 PM, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote:
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
The obvious difference is the power state of each node. The recent kernel has the finer power saving mode, and this might be the cause -- Mac has some secret that requires some node to be powered up.
Try to power on each node via hda-verb. For example, to power up the node 0x05, run like: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
Oops, a typo: the last argument must be 0x00, corresponding to D0: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x00
Bringing this back again, the command that makes it work is
hda-verb /dev/snd/hwC0D0 0x10 SET_POWER 0x00
OK, then please give alsa-info.sh output (run with --no-upload option) at both working and non-working cases.
And this is still needed as of 4.5.4
Of course, nothing has changed. I didn't hear from you since my previous question...
Wait, some relevant changes have been merged in 4.6. Please check 4.6 at first to be sure. Then give alsa-info.sh outputs.
Takashi
On 05/21/2016 12:42 AM, Takashi Iwai wrote:
On Sat, 21 May 2016 08:41:28 +0200, Takashi Iwai wrote:
On Sat, 21 May 2016 00:27:22 +0200, Laura Abbott wrote:
On 03/15/2016 12:49 PM, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote:
On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote:
Hi,
We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4.
The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)") but that didn't help.
Any ideas before asking for a bisect? Does this hardware version need to have the vref fixup as well?
The obvious difference is the power state of each node. The recent kernel has the finer power saving mode, and this might be the cause -- Mac has some secret that requires some node to be powered up.
Try to power on each node via hda-verb. For example, to power up the node 0x05, run like: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x01
Oops, a typo: the last argument must be 0x00, corresponding to D0: hda-verb /dev/snd/hwC0D0 0x05 SET_POWER 0x00
Bringing this back again, the command that makes it work is
hda-verb /dev/snd/hwC0D0 0x10 SET_POWER 0x00
OK, then please give alsa-info.sh output (run with --no-upload option) at both working and non-working cases.
And this is still needed as of 4.5.4
Of course, nothing has changed. I didn't hear from you since my previous question...
Wait, some relevant changes have been merged in 4.6. Please check 4.6 at first to be sure. Then give alsa-info.sh outputs.
Takashi
I'm assuming you were referring to de3df8a986b6 ("ALSA: hda - Keep powering up ADCs on Cirrus codecs") and 50fd4987c4f3 ("ALSA: hda - Don't trust the reported actual power state"). These were available in the 4.4.5 stable tree but the problem still persists with that tree.
alsa-info is attached.
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
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."
Thanks, Laura
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
participants (2)
-
Laura Abbott -
Takashi Iwai