quine-linux/docs/imac19-2-speaker-fix.md

iMac19,2 internal speakers: no sound on playback

TL;DR

Built-in speaker playback produces no audible sound at all, even though the HDA plumbing looks correct at every layer PipeWire/ALSA can see (unmuted volume, un-muted output pin, clean speaker-test device open). Root cause (via sibling-model research, not yet confirmed on this exact iMac19,2): audio on this hardware doesn't go straight from the CS8409's internal DAC to the speakers — it's relayed through external Texas Instruments TAS5764L speaker-amplifier chips over I2C, and a Cirrus CS42L83 companion codec, neither of which the in-tree (or our currently-vendored) driver ever initializes. The DAC happily outputs a signal; nothing downstream ever brings the amps out of reset to play it. No patch has been written or applied for this repo yet — this doc captures the investigation and the most promising existing prior art. See Current verification status.

Hardware / software identification

• Model: Apple iMac19,2 (2019, 21.5")
• Distro: Aurora (uBlue/Fedora Kinoite bootc image), Kinoite variant 44.20260908.1
• Kernel: 7.1.8-200.fc44.x86_64 — stock/in-tree snd_hda_codec_cs8409 (/lib/modules/.../kernel/sound/hda/codecs/cirrus/snd-hda-codec-cs8409.ko.xz). This machine has not yet been switched to this repo's own patched image — the mic fix in docs/imac19-2-mic-fix.md is also still unverified on real hardware as of that doc's last update. So whatever's happening here is a pre-existing quirk in the stock driver, unrelated to our own mic patch.
• Audio codec: Cirrus Logic CS8409, HDA vendor id 0x10138409, subsystem id 0x106b0f00 (same subsystem-id family the mic-fix doc groups with iMac18,1/iMac18,x).

Symptom

No audible sound from the built-in speakers under any output. Checked:

• wpctl status — sink Built-in Audio Analog Stereo present, unmuted, volume 0.92–1.00, not the wrong default device.
• amixer -c0 contents — PCM Playback Volume at 245/255 (~-1dB from max), unmuted (mute=0 reported, no explicit mute switch present at all for this control).
• speaker-test -c2 -twav opens the ALSA device and runs cleanly (no -16 Device or resource busy, no -19 No such device, no other open/setup error) — the kernel driver accepts the stream without complaint.

Ruled out, with evidence

• Wrong/muted PipeWire sink — wpctl status shows the correct sink selected and unmuted; this is a separate, already-known-good check from the mic doc's own investigation (that doc independently found and fixed an unrelated muted-sink issue on the same class of hardware).
• ALSA-level mute or zero volume — PCM Playback Volume is at 245/255; there is no separate Speaker Playback Volume/Switch control at all (only PCM, Mic, Internal Mic, Internal Mic Boost exist per amixer -c0 scontrols), so there's no separate speaker-path mute to check — consistent with the codec not exposing an amp-capable mixer control on this path at all (see Root cause).
• HDA pin disabled — /proc/asound/card0/codec#0, Node 0x24/0x25 (Pin Complex, [Fixed] Speaker at Int, DefAssociation=0x1, Sequence=0x0/0x1) both show Pin-ctls: 0x40: OUT — output enabled at the pin level, not disabled.
• Stream open failure — speaker-test opens and runs without any ALSA error; this isn't a "device doesn't exist"/"busy" failure.
• Kernel panic or crash on the audio path — dmesg/journalctl -k weren't reachable as this user (dmesg_restrict=1, no passwordless sudo available in this session) so this wasn't directly checked; nothing else observed (no hang, no dropped SSH/session) is consistent with a crash either way. Worth checking with root access before further work.

Root cause

Not confirmed on this exact machine yet, but strongly indicated by prior art on sibling Apple CS8409 hardware:

• Companion hardware, not a simple codec quirk: per rojoxstar/imac19-2-cs8409-linux (already referenced-and-shelved in the mic-fix doc), this exact 2019 iMac's internal speakers are driven by four TI TAS5764L amplifier chips plus a Cirrus CS42L83 companion codec sitting behind the CS8409 — not a direct CS8409-DAC-to-speaker path. That project reports getting internal speakers "audible on both sides at 44.1 kHz" on Ubuntu with kernel 7.0.0-31-generic, after amplifier-specific bring-up work, and explicitly warns: "Never try speculative TAS gain writes, including 0xCF, on the speakers" — i.e. wrong register writes to these chips are a real-hardware-damage risk, not just a "no sound" risk.
• Closer, Fedora-specific precedent: egorenar/snd-hda-codec-cs8409 issue #31, "iMac18,3 built-in speakers working on Fedora 43 / kernel 6.19.12 with additional TAS576 initialization" (iMac18,3 = 2017 27" 5K iMac, PCI subsystem 0x106b1000 — same subsystem-id family the mic doc already groups with our 0x106b0f00). Root cause as described there: the speaker path needs additional TAS576 boot/reset initialization that's simply missing from the stock driver, and separately, code that cleared speaker DACs 0x02/0x03 during cleanup was losing an already-working speaker state.
  • The actual patch for that report lives in a follow-on repo, network-garden-lab/imac18-3-cs8409-fedora-speaker-patch (Fedora-specific, two patch variants for kernel 6.19.12 and 7.0.12-201.fc44.x86_64 — the latter within one Fedora point release of our own 7.1.8-200.fc44.x86_64). Unlike the mic fix's vendored out-of-tree module, this is a ~1100-line patch against the in-tree kernel source itself (sound/hda/codecs/cirrus/cs8409{.c,.h} and cs8409-tables.c), adding (among others) imac_tas576_boot_reset_setup(), imac_tas576_tdm_slot_setup(), imac_cs42l83_reset() / imac_cs42l83_inithw(), and a new CS8409_FIXUP_IMAC_AMP PCI-quirk fixup keyed off subsystem id 0x106b1000 specifically (iMac18,3's id, not ours) — using the TAS576 family at I2C addresses 0xd8/0xda/0xdc/0xde and the CS42L83 at 0x90.
  • Its own README calls this "experimental, single-machine tested" and "a working result and investigation record, not a complete or upstream-ready solution," and separately warns that changing the sound profile in desktop sound settings mid-session "may temporarily disturb or break playback... playback may resume with unexpectedly loud noise."
• What this doesn't explain yet: neither prior-art project confirms the exact iMac19,2 / subsystem 0x106b0f00 combination — the closest confirmed case is iMac18,3 (0x106b1000, 27" 5K, likely 2-way stereo amp layout) and rojoxstar's own iMac19,2 work (4x TAS5764L). Whether our specific board has 2 or 4 TAS5764L chips, and at which I2C addresses, is unconfirmed — this needs an actual I2C bus scan on this machine, not assumed from either project.

The fix

Not yet written or applied. No patch exists in this repo for this issue. The most promising starting point is adapting network-garden-lab/imac18-3-cs8409-fedora-speaker-patch's imac18-3-cs8409-speaker-fedora-7.0.12.patch (closest Fedora kernel match) to our subsystem id and kernel 7.1.8-200.fc44.x86_64, following the same sibling-model-adaptation approach the mic fix already used successfully.

This is not something to attempt as a quick live edit:

• It patches core in-tree kernel HDA source, not a leaf out-of-tree module — a materially bigger lift than the mic fix's kmod-builder stage. It would need either a full kernel rebuild or repackaging the same functional change as an out-of-tree replacement module (mirroring how the mic fix's patches/snd-hda-codec-cs8409/ is built and installed into /usr/lib/modules/<kver>/extra/ to override the in-tree one — see docs/imac19-2-mic-fix.md).
• It writes directly to amplifier-chip registers over I2C. Per the rojoxstar project's explicit warning, a wrong write here risks damaging the physical speaker hardware, not just producing no sound or a kernel warning — this needs real care re-deriving/checking register values against our actual chip revision before any write is attempted on this machine, not a copy-paste of another model's values.
• Precisely because of that, this should go through this repo's same build-image-then-bootc switch-then-reboot discipline as the mic fix (never a live modprobe/register-poke on the running system), and ideally should not even reach that stage until the I2C topology on our exact board is confirmed to match one of the two prior-art cases above.

Current verification status

Investigation only, as of 2026-09-29. Ruled out the simple mute/volume/pin-disabled explanations directly on this hardware (see Ruled out). Identified two independent pieces of sibling-model prior art pointing at the same TAS5764L/TAS576 + CS42L83 amplifier-bring-up root cause, with one Fedora-specific patch (network-garden-lab/imac18-3-cs8409-fedora-speaker-patch) close enough in kernel version to be a realistic starting point. Nothing has been vendored, patched, or built yet. Next steps, in order:

1. Get root/sudo access on this machine and pull dmesg/journalctl -k around a speaker-test run, to see whether the stock driver logs anything about the amp/companion-codec path (the mic fix's own discovery process relied heavily on this kind of kernel-log evidence).
2. Scan the I2C bus for TAS5764L/CS42L83 addresses actually present on this board (2 vs 4 amps, and their real addresses) rather than assuming either prior-art project's numbers apply unmodified.
3. Only then evaluate adapting the 7.0.12-201.fc44.x86_64 patch, following the same vendor-and-patch-separately discipline as patches/snd-hda-codec-cs8409/.

Open risks / unknowns

• Unconfirmed on this exact model: closest confirmed cases are iMac18,3 (patch exists, Fedora, close kernel match, different subsystem id) and rojoxstar's own iMac19,2 work (matching model, but Ubuntu-based, driver internals not yet compared line-by-line against the Fedora patch).
• Real hardware-damage risk: explicit upstream warning against speculative amp register writes on these speaker amps — this is not a "worst case is silence" fix like the mic one.
• Packaging is a bigger lift than the mic fix: in-tree kernel source patch vs. a leaf out-of-tree module; needs a build-pipeline decision before any code is written (full kernel rebuild vs. out-of-tree replacement module).
• Playback-instability warning from the patch author: changing sound profile/configuration mid-session reportedly can cause temporary loud/broken playback on iMac18,3 with this patch applied — unknown whether that's specific to that patch's implementation or a hardware-level behavior that would recur here too.
• Root access needed: this investigation stopped at what a non-root session could observe (dmesg/journalctl -k were inaccessible here).
• Apple DSP / authenticated macOS SSV work in rojoxstar's repo is a distinct, unrelated blocker (docs/apple-dsp/CURRENT-BLOCKER.md in that repo, gated on an authenticated macOS Sequoia 24G90 install image) — that applies to advanced Apple-specific DSP/EQ features, not basic playback, and should not be confused with what's blocking sound here.

References

• https://github.com/rojoxstar/imac19-2-cs8409-linux
• https://github.com/egorenar/snd-hda-codec-cs8409/issues/31
• https://github.com/network-garden-lab/imac18-3-cs8409-fedora-speaker-patch
• docs/imac19-2-mic-fix.md — sibling-model subsystem-id grouping and the vendor-and-patch-separately packaging precedent this doc leans on.