Optional model-gated microphone DSP for Apple T2 MacBooks

[likidu]

Summary

On a MacBookPro16,1, Omarchy correctly installs the T2 kernel and audio configuration, and the internal microphone is detected. However, its raw capture level is too low for normal use in conferencing applications such as Zoom and Lark.

I am not reporting this as an Omarchy regression. I would like to discuss whether Omarchy should:

1. Document low microphone gain as a known T2 limitation; and/or
2. Eventually support optional, exact-model-gated microphone DSP when the required dependencies have an Arch-native packaging path.

Environment

• Hardware: MacBookPro16,1 — 2019 16-inch Intel MacBook Pro with Apple T2
• Omarchy: 4.0.1-1
• Kernel: linux-t2 7.1.8.arch1-3
• PipeWire: 1.6.8
• WirePlumber: 0.5.15
• T2 audio configuration: apple-t2-audio-config 0.4.r21.ga973d53-1
• Applications tested: Zoom and Lark

Diagnosis

Both applications used the same system-default source:

Apple Audio Device Internal Microphone

The source was:

• Correctly selected
• Unmuted
• At 100% / 0 dB
• The only application-visible microphone
• Used by both Zoom and Lark at unity stream gain

A recording made directly through PipeWire reproduced the low level outside either application.

Measured peaks:

Capture path Peak
━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━
Default source -38.7 dBFS
──────────────── ────────────
Raw channel 1 -39.6 dBFS
──────────────── ────────────
Raw channel 2 -49.3 dBFS
──────────────── ────────────
Raw channel 3 -37.0 dBFS

The T2 driver exposes a raw three-channel, 24-bit/48 kHz microphone array but no ALSA capture-gain or microphone-boost control. This appears consistent with the historically documented low-amplificationlimitation of the T2 Linux microphone path.

Tested DSP workaround

I tested the MacBookPro16,1 microphone graph from:

https://github.com/lemmyg/t2-apple-audio-dsp

It uses the Triforce LV2 beamformer:

https://github.com/chadmed/triforce

I installed only the microphone graph—not the project's speaker DSP. It combines the three array channels, applies the model-specific gain and high-pass filter, hides the raw source, and exposes a mono source named:

MacBook Pro T2 DSP Mic

The post-DSP recording peaked at -23.8 dBFS, approximately 14.9 dB louder, with no clipping observed. The graph and default-source selection also survived an audio-service restart.

This is useful validation on one machine, but I do not think the current workaround is suitable for an Omarchy PR as-is:

• triforce-lv2 is not currently available as an Arch/AUR package.
• My test used the official Ubuntu amd64 build extracted into the user LV2 directory.
• The DSP graph encodes model-specific microphone geometry and gain.
• The upstream DSP project describes itself as work in progress.
• Omarchy's existing audio-tuning framework currently handles speaker sinks, not microphone sources.

Suggested direction

Would Omarchy maintainers be open to either or both of the following?

1. Documentation now

Add a note to the T2 Mac support documentation explaining that installing apple-t2-audio-config exposes the internal microphone, but some models may still have very low raw capture gain.

The documentation could link to the upstream T2 DSP project while clearly noting its supported models and work-in-progress status.

I would be happy to prepare this small documentation PR.

2. Optional microphone tuning later

Once the DSP assets and Triforce have maintained Arch-native packages, consider an input-tuning mechanism with these constraints:

• Match exact supported DMI model identifiers—starting only with the verified MacBookPro16,1
• Never apply one microphone graph to every T2 Mac
• Keep microphone and speaker DSP independently selectable
• Fail safely when the plugin or target source is unavailable
• Provide explicit enable, disable, and rollback behavior
• Persist the DSP source as the default input
• Avoid restarting active conferencing clients where possible
• Test idempotence, unsupported hardware, missing dependencies, service restarts, and uninstall behavior

This might fit better as a separate omarchy audio input tuning mechanism than as an extension implicitly bundled with the current speaker-tuning command.

Questions

1. Would a documentation PR describing the current T2 microphone limitation be welcome?
2. Does Omarchy want to own optional model-specific microphone DSP, or should this remain entirely with the T2 Linux projects?
3. If Omarchy is interested, where should the Arch packaging for triforce-lv2 and the model-specific DSP assets live?