After 3.3.8 -> 3.4.1 upgrade I have no headphones output

pezcurrel · 2012-06-21 17:01:19

Hi,
I'm running arch linux on a macbook 5,2 with "Audio device: NVIDIA Corporation MCP79 High Definition Audio (rev b1)" (from lspci) and codec Realtek ALC889A.
On arch linux with kernel 3.3.8-1-ARCH and "options snd-hda-intel model=mbp3" I had no problems with sound; with 3.4.3-1-ARCH the mixer channels shows some differences (see below), and I can't get any output from the headphones-out (so, I also have no possibility to connect the laptop to an amplifier).
I tried all I could with mixer and using every model which made some sense for "options snd-hda-intel model=...", but with no success.

An edited diff output follows to show the differences in mixer channels...

$ diff amixer_output_with_kernel_3.3.8 amixer_output_with_kernel_3.4.1

> Simple mixer control 'Bass Speaker',0

< Simple mixer control 'Surround',0
< Simple mixer control 'Line Boost',0

< Simple mixer control 'Channel Mode',0
< Items: '2ch' '4ch'
< Item0: '2ch'

> Simple mixer control 'Auto-Mute Mode',0
> Items: 'Disabled' 'Enabled'
> Item0: 'Enabled'

< Items: 'Mic' 'Front Mic' 'Line' 'CD'

> Items: 'Mic' 'Line'

nTia89 · 2012-06-21 17:06:18

according with macbook page on our wiki,
try to see if with the new kernel the sound options are changed....

Šaran · 2012-06-21 17:56:22

With kernel 3.0 I lost headphones channel in alsamixer, but with 3.4 it's back - I almost went deaf.
So, something was obviously changed.

pezcurrel · 2012-06-22 10:58:19

nTia89 wrote:

according with macbook page on our wiki,
try to see if with the new kernel the sound options are changed....

thanks, I found no direct reference on this but some useful links... now, using hda-analyzer (http://www.alsa-project.org/main/index.php/HDA_Analyzer), I found out that with just this "diff" headphones work ok...

Diff for codec 0/0 (0x10ec0885):
--- 
+++ 
@@ -178,27 +178,27 @@
     DefAssociation = 0x4, Sequence = 0x0
     Misc = NO_PRESENCE
   Unsolicited: tag=0x00, enabled=0
   Connection: 5
      0x0c* 0x0d 0x0e 0x0f 0x26
 Node 0x15 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
   Control: name="Headphone Playback Switch", index=0, device=0
     ControlAmp: chs=3, dir=1, idx=0, ofs=0
-  Control: name="Headphone Jack", index=0, device=0
+  Control: iface="card", name="Headphone Jack", index=0, device=0
   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
   Amp-In vals: [0x00 0x00]
   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
   Amp-Out vals: [0x00 0x00]
   Pincap 0x0000373c: IN OUT HP Detect
     Vref caps: HIZ 50 GRD 80 100
   Pin Default 0x012b4050: [Jack] HP Out at Ext Rear
     Conn = Comb, Color = Green
     DefAssociation = 0x5, Sequence = 0x0
-  Pin-ctls: 0xc0: OUT HP VREF_HIZ
+  Pin-ctls: 0xc1: OUT HP VREF_50
   Unsolicited: tag=0x01, enabled=1
   Connection: 5
      0x0c 0x0d 0x0e* 0x0f 0x26
 Node 0x16 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
   Control: name="Bass Speaker Playback Switch", index=0, device=0
     ControlAmp: chs=3, dir=1, idx=0, ofs=0
   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
   Amp-In vals: [0x00 0x00]

...but the problem is I can't find out how to apply this without having to use hda-analyzer every time, since hda-analyzer's "export" feature, which is supposed to generate a python script to run at boot to patch the card, doesn't work here....
any suggestions?

Last edited by pezcurrel (2012-06-22 11:42:15)

pezcurrel · 2012-06-22 12:22:51

Hurrah, I managed to make the export feature of hda-analyzer work by commenting out the 2 lines calling "set_vol_knb" in hda_codec.py (it's part of the hda-analyzer "package") (as suggested here: http://forums.fedoraforum.org/showthread.php?t=274065 ).
So now I have the little python "patcher" script which I exported from hda-analyzer running at boot, called by /etc/rc.local, and switching "internal speakers/headphones-external ampli" works again as it is supposed to, by just plugging in-out the jack.
I also tested mic in and line in and they both work.
I can't test spdif in/out since I have no external digital device to attach, but at least the red light inside "the hole" turns on when I enable IEC958 in mixer settings (although analog output persists, so I'm not sure...).
So, for my macbook 5,2, the following alsa setup is working...

/etc/modprobe.d/alsa.conf

options snd-hda-intel power_save=0

("model=mbp3" is no longer needed; "power_save=0" is needed, though, because otherwise after the "card" enters and exits the "power save mode" it turns to the old behaviour)

/etc/mb5,2_hda_fix.py

#!/usr/bin/env python2

import os
import struct
from fcntl import ioctl

def __ioctl_val(val):
  # workaround for OverFlow bug in python 2.4
  if val & 0x80000000:
    return -((val^0xffffffff)+1)
  return val

IOCTL_INFO = __ioctl_val(0x80dc4801)
IOCTL_PVERSION = __ioctl_val(0x80044810)
IOCTL_VERB_WRITE = __ioctl_val(0xc0084811)

def set(nid, verb, param):
  verb = (nid << 24) | (verb << 8) | param
  res = ioctl(FD, IOCTL_VERB_WRITE, struct.pack('II', verb, 0))

FD = os.open("/dev/snd/hwC0D0", os.O_RDONLY)
info = struct.pack('Ii64s80si64s', 0, 0, '', '', 0, '')
res = ioctl(FD, IOCTL_INFO, info)
name = struct.unpack('Ii64s80si64s', res)[3]
if not name.startswith('HDA Codec'):
  raise IOError, "unknown HDA hwdep interface"
res = ioctl(FD, IOCTL_PVERSION, struct.pack('I', 0))
version = struct.unpack('I', res)
if version < 0x00010000:        # 1.0.0
  raise IOError, "unknown HDA hwdep version"

# initialization sequence starts here...

set(0x15, 0x707,   0xc1) # 0x150707c1 (SET_PIN_WIDGET_CONTROL)

os.close(FD)

edit /etc/rc.d/alsa adding "/etc/mb5,2_hda_fix.py" like below (soon before the end of the "start" "case block") and make sure "alsa" is in your DAEMONS array in /etc/rc.conf (when "/etc/mb5,2_hda_fix.py" is added to /etc/rc.local instead, it often fails, for some reason)...

[...]
    if [[ -e /sys/module/snd_hda_intel/parameters/power_save ]] \
          && (( $POWERSAVE )); then
      echo $POWERSAVE > /sys/module/snd_hda_intel/parameters/power_save
      [[ -c /dev/dsp ]] && echo 1 > /dev/dsp
    fi
    /etc/mb5,2_hda_fix.py
    ;;
  stop)
    SAVE_VOLUME=${SAVE_VOLUME:-yes}
[...]

if you use upower + pm-utils to have power management, you will also need to edit /etc/pm/sleep.d/90alsa as follows, to restore the patch after suspension/hybernation...

#!/bin/sh
#
# 90alsa: suspend/wakeup ALSA devices

case "$1" in
hibernate|suspend)
rc.d stop alsa
;;
thaw|resume)
aplay -d 1 /dev/zero
rc.d start alsa
;;
*) exit $NA
;;
esac

Thanks, bye

Last edited by pezcurrel (2012-06-23 16:52:16)

falbani · 2012-08-02 19:25:41

I just wanted to thank you pezcurrel!!!

I tried a lot of things first because I thought that your solution was dirty, but it is the only one that works... hehehe...

Have you found any alternative?

helmuthdu · 2012-12-26 15:21:11

I have created a systemd service for this, $ nano /etc/systemd/system/alsa-fix.service

[Unit]
Description=Fix headphone volume issue on MacBook5,2

[Service]
Type=oneshot
ExecStart=/bin/sh -c "python2 /etc/alsa_fix.py"

[Install]
WantedBy=multi-user.target

save this script from pezcurrel (amazing fix btw) like /etc/alsa_fix.py

#!/usr/bin/env python2

import os
import struct
from fcntl import ioctl

def __ioctl_val(val):
  # workaround for OverFlow bug in python 2.4
  if val & 0x80000000:
    return -((val^0xffffffff)+1)
  return val

IOCTL_INFO = __ioctl_val(0x80dc4801)
IOCTL_PVERSION = __ioctl_val(0x80044810)
IOCTL_VERB_WRITE = __ioctl_val(0xc0084811)

def set(nid, verb, param):
  verb = (nid << 24) | (verb << 8) | param
  res = ioctl(FD, IOCTL_VERB_WRITE, struct.pack('II', verb, 0))

FD = os.open("/dev/snd/hwC0D0", os.O_RDONLY)
info = struct.pack('Ii64s80si64s', 0, 0, '', '', 0, '')
res = ioctl(FD, IOCTL_INFO, info)
name = struct.unpack('Ii64s80si64s', res)[3]
if not name.startswith('HDA Codec'):
  raise IOError, "unknown HDA hwdep interface"
res = ioctl(FD, IOCTL_PVERSION, struct.pack('I', 0))
version = struct.unpack('I', res)
if version < 0x00010000:        # 1.0.0
  raise IOError, "unknown HDA hwdep version"

# initialization sequence starts here...

set(0x15, 0x707,   0xc1) # 0x150707c1 (SET_PIN_WIDGET_CONTROL)

os.close(FD)

and the last thing: $ systemctl enable alsa-fix.service

Last edited by helmuthdu (2012-12-26 15:27:09)

msuperdock · 2015-06-17 23:35:32

I have had the same problem (only headphones not working) running 3.18.14-1-MANJARO on my Macbook 5,2. I tried the systemd service by helmuthdu, and it fixed the problem. Much thanks to both of you.

ewaller · 2015-06-18 04:42:56

Two problems here:

This is a two and a half year old thread and
this is not an Arch Linux question. Please ask on the forums of your chosen distribution. (Arch != Manjaro)

closing

Last edited by ewaller (2015-06-18 04:43:12)

Arch Linux

#1 2012-06-21 17:01:19

After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#2 2012-06-21 17:06:18

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#3 2012-06-21 17:56:22

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#4 2012-06-22 10:58:19

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#5 2012-06-22 12:22:51

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#6 2012-08-02 19:25:41

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#7 2012-12-26 15:21:11

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#8 2015-06-17 23:35:32

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

#9 2015-06-18 04:42:56

Re: After 3.3.8 -> 3.4.1 upgrade I have no headphones output

Board footer