MacBookPro12,1 (2015): CS4208 woofers silent; Air pin map + ACP 4.0 dead analog #12217

Activity

1. TRIBUSeric commented on Sep 17, 2026

   

   TRIBUSeric

   on Sep 17, 2026

   Author

   More actions

   Follow-up: raw hw:PCH,0 4-channel is analog-silent on the woofers too.

   Isolated test: pro-audio profile, api.alsa.path=hw:PCH,0, 4ch FL/FR/RL/RR, simple upmix. Tweeters muted (Speaker mixer), Bass Speaker 100%, 250 Hz for 6s. DAC 0x04 was D0, unmuted, stream on channel 2. Acoustic result: silence.

   So this is not limited to ACP surround40:1. Both the extra-out copy on analog-stereo and explicit 4ch hw: leave the woofer DAC looking busy and the drivers silent. Tweeters on analog-stereo still work.

   We’ve put the machine back on analog-stereo (tweeters only).
2. omarchybot

   added

   bugSomething isn't workingSomething isn't working

   compatibilityMake Omarchy work better on everything!Make Omarchy work better on everything!

   on Sep 27, 2026
3. the-lerhin commented on Oct 3, 2026

   

   the-lerhin

   on Oct 3, 2026

   More actions

   Follow-up from another MacBookPro12,1: codec ground truth + why the woofers stay silent

   Same machine as the report (MacBookPro12,1, CS4208 0x10134208, codec SSID 106b:7b00,
   controller 8086:9ca0 / PCI SSID 8086:7270). Omarchy 4.0.4-1, kernel 7.2.5-4-omarchy.
   I went one level deeper into the codec and can add hard data to this issue.

   1. The Air pin map is confirmed as a real, separate bug

   model=,mbp11 (forced on card1 — the model array is per HDA controller, so the plain
   model=mbp11 that fixes the iMac lands on the HDMI controller instead) gives:

   CS4208: picked fixup mbp11 (model specified)
   autoconfig for CS4208: line_outs=2 (0x12/0x13/0x0/0x0/0x0) type=speaker
   

   vs line_outs=1 (0x12) under the 8086:7270 quirk. So yes — keying the CS4208 quirk on the
   generic Intel PCI SSID really is what drops the second speaker pin here (see omarchy-pkgs#510).

   2. Ground-truth EFI codec capture (driverless, via MMIO)

   Booted once with snd_hda_intel blacklisted and read the CS4208 over the controller's
   immediate-command registers (ICOI/ICII/ICIS) — i.e. the state EFI leaves before Linux touches
   the link. Compared against the driver's state afterwards:

   coef	EFI (clean)	driver	note
   0x1f	0x0000	0x0400	PLL clock: locked → latched fault
   0x33	0x0082	0x0001
   0x34	0x0302	0x1c01
   0x18	0x0400	0x0400	same
   0x03	0xfbaa	0xfbaa	same
   pin 0x12/0x13	cfg …110/…112, ctl 0x40	same	both enabled by EFI
   GPIO data/mask/dir	0x00/0x01/0x01	0x01/0x01/0x01

   So EFI leaves the codec clock-locked with both speaker pins enabled, and it is the
   driver bring-up that changes exactly three coefficients. This is the same failure signature
   @thomas-shirley documented on MacBook8,1 (0x1f: 0x0 good, 0x400 latched clock fault).

   Restoring the EFI values of 0x33/0x34 at runtime did not wake the woofers, and 0x1f
   cannot be cleared while the driver is bound (writing 0x0 reads back 0x400) — also matching
   that write-up.

   3. The clock fault is preventable on 12,1 — but it does not fix the woofers

   I built the two non-TDM parts of the MacBook8,1 fix against 7.2.5 (both patches are
   hardware-gated on our exact IDs, so they compiled unmodified):

   • snd-hda-intel → attach to the live EFI link without reset (hda_intel_init_chip(chip, false))
     for 8086:9ca0 / ssid 8086:7270; dmesg shows MacBook8,1: attaching to running EFI link without reset.
   • snd-hda-codec-generic → skip init_aamix_paths/init_analog_input/init_input_src/init_digital
     for vendor_id 0x10134208 (as on the 8,1 this is what re-latches the fault even without the reset).
   • options snd-hda-intel single_cmd=1 power_save=0.

   Result: coef 0x1f = 0x0 end-to-end — the latch is gone, first time the codec has stayed
   clock-locked under Linux here. So the "prevent the latch, don't repair it" strategy genuinely
   applies to this board too.

   But the woofers still produce no sound. With the clean codec state, force-routed 150 Hz into
   the woofer DAC only (analog-surround-40, tone only in RL/RR, both ALSA controls untouched):

   node 0x03  stream=5 channel=0  amp 0x7f   (tweeters, silent channels)
   node 0x04  stream=5 channel=2  amp 0x7f   (woofers, carries the 150 Hz)
   

   Acoustic result: silence (tweeter path still works). So neither the Air pin map, nor routing,
   nor the clock fault is what keeps the woofers quiet.

   (Side note for whoever picks this up: muting either ALSA control — Speaker or
   Bass Speaker — silences the whole output, e.g. 3 kHz with Bass Speaker off is inaudible even
   though node 0x03's amp stays at 0x7f. There is a shared output stage behind both controls, so
   per-DAC muting cannot be used to isolate the two drivers.)

   4. Where I'd look next

   On MacBook8,1 the CS4208 speakers are a 4-channel TDM stream into an external class-D amp
   (converter 0x0a → pin 0x1d), not the analog DAC. This board exposes the same digital blocks
   (0x0a/0x0b 8-ch digital, pins 0x1d/0x1e, vendor node 0x24) even though the analog
   0x03/0x04 → 0x12/0x13 path is what the auto-parser picks. It is worth checking whether the
   12,1 woofers actually sit on the TDM/class-D path and only the tweeters are analog — which
   would explain why analog bring-up alone never reaches them. I did not test the TDM/cs420x side
   of the 8,1 fix here (it also rewrites the TDM prepare and re-applies the 8,1 EFI coef image,
   and would have taken the machine further from stock while breaking the internal mic).

   Reproduce / data

   • Forcing the fixup: /etc/modprobe.d/cs4208-mbp121.conf → options snd-hda-intel model=,mbp11.
   • Driverless EFI capture: pmgart/macbook8-1-debian-guide audio/diagnostics/read-clock-driverless.py
     (adapted; reads coefs 0x00..0x3f, GPIO, pins 0x10/0x12/0x13).
   • The two kernel patches above are install.azx.driver.sh + install.generic.driver.sh from
     thomas-shirley/macbook8.1-speaker-driver, unmodified (their gates are hardware-ID based).
   • Full EFI coef dump, driver coef dump, and dmesg available on request.

   Happy to test a candidate cs420x/TDM patch if someone takes this on.
4. omarchybot commented on Oct 12, 2026

   

   omarchybot

   on Oct 12, 2026

   Collaborator

   More actions

   Checked against current quattro (9480d1b) and the current kernel package in omacom/omarchy-pkgs. Claude Opus 5.5 did the diagnosis. Codex at medium effort reviewed it separately as a second opinion and agreed; it could not reach the GitHub API, so it read the issue body but not the comments, and its independence is not guaranteed. Nothing was reproduced: a VM has no CS4208, so this is a reading of the source and of the data in this thread, not a test.

   The Air pin map is confirmed in source, and it is Omarchy's own patch. The 8086:7270 entries are not upstream. They are added by pkgbuilds/linux-omarchy-bore/0514-sound-fixes-2.patch in omarchy-pkgs, which is still on master (linux-omarchy is now a meta package for linux-omarchy-bore). The patch puts SND_PCI_QUIRK(0x8086, 0x7270, "MacBookAir 7,2", CS4208_MAC_AUTO) in cs4208_fixup_tbl and SND_PCI_QUIRK(0x8086, 0x7270, "MacBookAir 7,2", CS4208_MBA6) in cs4208_mac_fixup_tbl. snd_hda_pick_fixup matches PCI subsystem IDs before it falls back to the codec subsystem ID. So when CS4208_MAC_AUTO does its second lookup, 8086:7270 → MBA6 wins before the upstream 106b:7b00 → MBP11 entry for this machine is ever tried. That matches the picked fixup … for PCI SSID 8086:7270 and line_outs=1 (0x12) both of you saw. omacom/omarchy-pkgs#510 reports the same quirk silencing an iMac16,2. Fixing it means keying that entry on the MacBook Air's codec SSID instead, in omarchy-pkgs, which is outside what this bot works on.

   Fixing the pin map will not bring the woofers back on its own. @the-lerhin forced mbp11, got line_outs=2 (0x12/0x13), kept the codec clock-locked, and the woofers were still silent. So nothing here establishes why they stay quiet. The suggestion that the woofers sit on the CS4208 digital/TDM path (converter 0x0a → pin 0x1d) rather than on DAC 0x04 → pin 0x13 is plausible but untested on this model. It fits how the Late 2015 iMacs and the MacBook8,1 drive their speakers, but no one has yet played sound through 0x0a → 0x1d on a MacBookPro12,1. The faint tone on raw hw: 4-channel in the original report doesn't settle it either way.

   Nothing in omarchy fixes this today. quattro ships nothing for MacBookPro12,1 audio, and no open pull request covers it. #10458 and #12689 set iMac16,x speakers to Analog Surround 4.0, and both detectors exclude MacBookPro12,1. That is right, since surround-40 was silent here. I have not filed a hook. The install script suggested in the report would bring back the second pin but not the sound, so it would not fix the problem. Neither model found a duplicate issue in this repository.

   This waits on the maintainer for the 8086:7270 quirk in omarchy-pkgs (tracked in omacom/omarchy-pkgs#510). The woofers stay open until someone shows sound through the digital path on this board.