一台 2017 年款 iMac 长期运行 Arch Linux。扬声器、无线网卡、蓝牙、摄像头和麦克风这些在 macOS 下理所当然可以工作的内置设备，到了 Linux 下却有着完全不同的兼容性表现。
其中最特殊的是内置麦克风。
摄像头的问题很简单：硬件年代较早，与现在的 2K USB 摄像头相比，画质已经明显落后。蓝牙同样受到硬件世代限制。无线网卡的情况稍有不同，硬件本身并不差，在 Windows 下表现仍然很好，Linux 下的问题更多来自驱动兼容性。
麦克风则完全不同。
这块内置麦克风本身的录音质量并不落后，实际测试甚至不逊于现在常见的 USB 摄像头集成麦克风。过去之所以长期被认为“不能用”，问题主要出在 Linux 驱动和音频栈，而不是麦克风硬件本身。
意外发现：拔掉 USB 麦克风以后，内置麦克风竟然还能工作
这台机器平时连接着一台 2K USB 摄像头，同时也把摄像头自带的 USB 麦克风作为录音设备使用。
一次系统完整升级后，系统依次更新了 Arch 官方仓库软件、AUR 软件以及 Flatpak 应用，并重新启动进入新内核。
这次升级后的声音输出完全正常。
随后在测试音频设备时，USB 摄像头被物理拔掉。本来预期系统应该因此失去可用麦克风，结果却发现录音仍然正常。
检查 PipeWire 后确认，正在工作的并不是已经拔掉的 USB 麦克风，而是 iMac 自己的内置麦克风。
当前系统能够明确区分两个独立的输入源：
- iMac 内置的 HDA 麦克风
- USB 2K 摄像头集成的麦克风
内置麦克风当前已经被设置为正常的 PipeWire 输入 source，并且能够实际录制声音。审计时 ALSA 也能够看到 CS8409/CS42L83 Analog capture 设备。
这带来了一个问题：
这只麦克风究竟是什么时候开始正常工作的？
CS8409 与 snd_hda_macbookpro
这代 iMac 的音频系统使用 Cirrus Logic CS8409/CS42L83 相关硬件。
Linux 内核自带的 CS8409 支持长期无法完整覆盖部分 Intel Mac，因此系统使用了 snd_hda_macbookpro 项目的修正版驱动，并通过 DKMS 管理。
正常情况下，修正版模块会安装到类似：
/lib/modules/<kernel-version>/updates/dkms/snd-hda-codec-cs8409.ko.zst
而不是使用内核树中原生的 CS8409 模块。
当前系统已经确认：
Kernel:
7.1.8-arch1-3
DKMS:
snd_hda_macbookpro/0.1 installed
Module:
/lib/modules/7.1.8-arch1-3/updates/dkms/snd-hda-codec-cs8409.ko.zst
这意味着内核升级以后，DKMS 自动重新编译了修正版驱动，而且新内核启动后仍然正确使用该模块。
从系统日志倒推历史
为了找到麦克风开始工作的时间，对现存的 systemd journal、pacman 历史、DKMS 状态、PipeWire、ALSA、AUR 缓存以及驱动源码历史进行了一次只读取证。
最关键的历史日志出现在：
2026 年 1 月 23 日 22:25 JST
当时运行的还是：
Linux 6.18.3-arch1-1
内核启动过程中已经出现：
snd_hda_intel: Primary cs8409
snd_hda_intel: Primary patch_cs8409 NOT FOUND trying APPLE
紧接着 CS8409 自动配置中明确出现：
inputs:
Internal Mic=0x45
Mic=0x3c
几秒之后又创建了：
HDA Intel PCH Mic
因此至少可以确定三件事：
- 最迟在 2026 年 1 月 23 日，修正版 CS8409 驱动已经实际接管；
- 内核当时已经识别
Internal Mic； - ALSA/HDA 层当时已经创建了麦克风输入设备。
这比 2026 年 8 月发现麦克风可以正常录音早了半年多。
1 月 23 日就是麦克风修好的日期吗？
不能这样下结论。
现存 journal 更早可以追溯到 1 月 22 日附近，但最早一批启动日志中的 early kernel 部分已经不完整。
因此不存在足够证据证明：
2026-01-22：不支持
2026-01-23：突然支持
更准确的说法是：
2026 年 1 月 23 日是现存系统日志中最早能够直接证明修正版驱动已经识别内置麦克风的时间。
更早是否已经如此，现有日志已经无法判断。
“识别麦克风”和“麦克风真的能录音”不是一回事
这是整个调查中最重要的区别。
Linux 内核输出：
Internal Mic=0x45
只能证明驱动识别到了相应的输入节点。
出现：
HDA Intel PCH Mic
也只能证明系统建立了输入设备。
它们不能百分之百证明：
麦克风
↓
ADC
↓
ALSA Capture
↓
PipeWire
↓
应用程序
↓
真正得到有效音频数据
这条链路当时已经全部工作。
历史 journal 中没有保留下来能够直接证明“成功录制到了声音”的 capture stream 日志，也没有找到历史录音文件或应用状态能够确定首次成功录音的时间。
因此最终只能得出一个严格的结论：
现存系统证据无法确定真实录音功能首次可用的具体时间。
2026 年 5 月和 6 月的声卡修复又是什么？
后来的系统维护记录显示，2026 年 5 月曾重新处理 snd_hda_macbookpro 驱动。
当时一轮 DKMS 安装在 Linux 7.0.7 上失败。
2026 年 6 月再次升级到 Linux 7.0.11 后，修正版驱动重新构建成功。
到了 2026 年 8 月，系统升级到 Linux 7.1.8，DKMS 又一次自动为新内核完成构建。
但由于 2026 年 1 月的日志中已经存在：
Primary cs8409
Internal Mic=0x45
HDA Intel PCH Mic
所以 5 月和 6 月的操作明显不是“Linux 第一次认识内置麦克风”的时间点。
它们更像是后续驱动维护和内核升级后的 DKMS 修复。
这些操作是否改善了真正的 capture path，则已经无法从现存历史数据中证明。
也不是 Linux 7.1.8 突然修好了麦克风
2026 年 8 月这次升级同时更新了多个与音频有关的组件，包括：
- Linux 7.1.8
- PipeWire 1.6.8
- DKMS 3.4.2
- 新版 Cirrus firmware
- 重新为新内核构建的
snd_hda_macbookpro
因此最初很容易怀疑，是这次系统升级突然让内置麦克风恢复了工作。
历史日志否定了这个简单解释。
Linux 6.18.3 时，内核就已经明确识别这只麦克风。因此 7.1.8 至少不是“第一次识别麦克风”的版本。
它可以解释当前系统为什么工作稳定，却无法证明它是第一次真正修复录音功能的版本。
最可能发生的事情
结合所有现存证据，最合理的历史可能非常简单。
内置麦克风很可能已经正常或者接近正常相当长时间。
但是机器长期连接着一台 USB 摄像头，而摄像头自己又带有 USB 麦克风。日常使用时一直有一个明确可用的外置输入设备，因此没有必要重新验证曾经不能工作的内置麦克风。
于是系统逐渐经过：
Linux 内核更新
↓
CS8409 驱动更新
↓
ALSA 改进
↓
PipeWire 改进
↓
snd_hda_macbookpro 持续维护
内置麦克风可能早已跨过了“能够实际使用”的临界点，只是这个变化没有被注意到。
直到某一天外置 USB 麦克风被拔掉：
USB Mic 消失
↓
Internal Mic 仍然存在
↓
尝试说话
↓
音量表开始变化
↓
实际录音正常
这才发现：
原来它已经可以用了。
系统取证也认为，“麦克风可能早已正常，只是在拔掉 USB 麦克风后才第一次被注意到”是符合现有证据的解释，只是由于缺少历史录音日志，它仍然只能被视为推断，而不是可以证明的事实。
一块并不过时的老麦克风
这件事也说明，老电脑中的不同硬件不能简单归结为“年代久了，所以落后”。
2017 年的摄像头与今天的 2K 摄像头相比，画质差距是真实存在的。
蓝牙版本也会受到硬件世代限制。
无线网卡可能仍然具有不错的硬件性能，但在 Linux 下受到驱动兼容性制约。
而麦克风则完全是另一回事。
只要麦克风单元本身、模拟前端和 ADC 设计足够好，它并不会像摄像头分辨率一样因为几年过去就迅速失去使用价值。
实际测试中，这台 iMac 的内置麦克风声音质量完全可以继续承担日常语音、视频会议和录音输入任务。
真正长期阻碍它工作的，并不是麦克风硬件，而是软件支持。
当前的设备分工
内置麦克风恢复可用以后，并不意味着外置摄像头必须拆除。
更合理的配置反而是：
视频：
外置 2K USB 摄像头
音频输入：
iMac Internal Microphone
音频输出：
iMac Internal Speakers
这样既保留现代 2K 摄像头更好的画质，又可以利用 iMac 本身质量不错的麦克风。
而且外置摄像头与麦克风不再形成强绑定：
即使 USB 摄像头被临时拔掉，系统仍然具有完整的声音输入和输出能力。
最终结论
根据现存系统证据，可以确定：
最迟在 2026 年 1 月 23 日，Linux 下的修正版 CS8409 驱动已经识别并创建了 iMac 的内置麦克风输入设备。
但由于缺少历史 capture stream 和实际录音数据证据：
无法确定这只麦克风究竟在哪一天第一次真正能够正常录音。
2026 年 8 月的发现更可能只是一次偶然的验证，而不是麦克风刚刚获得支持。
这只长期被认为“不支持 Linux”的内置麦克风，很可能已经默默正常工作了相当长一段时间。
真正发生变化的或许并不是硬件。
只是 Linux 的驱动和音频栈，终于追上了它。