Match the QEMU audio mixer to the Mac output device rate - #283
Open
stevederico wants to merge 2 commits into
Open
stevederico wants to merge 2 commits into
stevederico wants to merge 2 commits into
Conversation
QEMU's audiodev defaults to a 44100 Hz mixer regardless of the host output device. When the Mac's default output device runs at any other rate, the guest's PCM stream is drained at the wrong speed and playback drifts. At 48000 Hz, the macOS built-in default, a 20.000 s clip plays in about 19.0 s. Query CoreAudio for the default output device's nominal rate and pass it as out.frequency/in.frequency so the mixer and the device agree. Fall back to 48000 when the query cannot answer. Measured with a 20.000 s tone played by pw-play in the guest and timed from the host over an SSH forward, so the guest clock is outside the measurement path (8-10 runs per condition): device 48000, before: 19.033 s / 19.090 s (about 4.8% fast) device 48000, after: 20.158 s (sd 0.019) device 44100, before: 20.013 s / 19.867 s device 44100, after: 20.161 s (sd 0.017) Both rates now land on the same figure, so playback speed no longer depends on the host device rate. The residual 0.16 s is constant pw-play startup and is present in every configuration.
The launcher now passes the Mac output device's rate to the audiodev, so the exact -audiodev line the test pinned no longer matched. Give the test a system_profiler shim that reports a 44100 Hz default output device and expect out.frequency and in.frequency at that rate, which also checks the detection instead of the 48000 fallback.
digital-brew
pushed a commit
to digital-brew/try-omarchy
that referenced
this pull request
Sep 29, 2026
QEMU's audiodev opens its mixer at 44100 Hz regardless of the Mac's output device. With the device at macOS's default 48000 Hz the guest's PCM stream is drained at the wrong speed and every app plays about 5 percent fast and sharp. Read the default output device's nominal rate from CoreAudio through system_profiler and pass it as out.frequency and in.frequency, falling back to 48000 when the query cannot answer. From omacom#283. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018W8fhTegW8d16zpAjRpsT9
digital-brew
pushed a commit
to digital-brew/try-omarchy
that referenced
this pull request
Sep 29, 2026
QEMU's audiodev opens its mixer at 44100 Hz regardless of the Mac's output device. With the device at macOS's default 48000 Hz the guest's PCM stream is drained at the wrong speed and every app plays about 5 percent fast and sharp. Read the default output device's nominal rate from CoreAudio through system_profiler and pass it as out.frequency and in.frequency, falling back to 48000 when the query cannot answer. From omacom#283. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018W8fhTegW8d16zpAjRpsT9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #265.
Cause
QEMU's audiodev opens its mixer at 44100 Hz by default, whatever the Mac's output device is doing. When the default output device runs at a different rate, the guest's PCM stream is drained at the wrong speed and playback drifts. 48000 Hz is the macOS built-in default, which is why the symptom is the common case.
This is not specific to the SDL backend. I rebuilt the runtime with
--audio-drv-list=sdl,coreaudioto check, andcoreaudiodrifts too, slightly worse and very consistently (18.531 s, sd 0.021). It is also not the guest's rate: forcing the guest's PipeWire graph to 44100 while the device stayed at 48000 changed nothing (18.515 s).Setting
out.frequencyto the device's rate removes the drift; setting it to a fixed 48000 simply reverses the mismatch on a 44100 device (21.920 s, ~9.6% slow). So the rate has to be read from the host rather than hardcoded.Fix
Query CoreAudio via
system_profiler/plutilfor the default output device's nominal rate and pass it asout.frequency/in.frequency. Falls back to 48000 if the query cannot answer. No new dependencies.Measurements
A 20.000 s stereo tone played with
pw-playin the guest, timed from the host over an SSH port forward so the guest clock is outside the measurement path. The guest's own timing was recorded in parallel and agreed with the host to within ~40 ms on every run. 8-10 runs per condition.Both rates now land on the same value, so playback speed no longer depends on the device rate. The residual 0.16 s is constant
pw-playstartup and appears in every configuration, including the ones that were already correct.Detection was verified to return the right value at 44100, 48000, 88200 and 96000.
Limitations
Testing notes
Measured on a MacBook Air (M3), macOS 15.6, against a re-signed 0.4.1 bundle and a runtime built from this tree. Single unrepeated timings are not reliable here: per-run spread on some configurations reaches 0.4 s, and an early round of one-shot manual tests produced both fast and correct results at the same device rate. All figures above are 8-10 run means with standard deviations.