fix(audio): include tap in aggregate device creation dictionary#14
Open
sondt2709 wants to merge 1 commit into
Open
fix(audio): include tap in aggregate device creation dictionary#14sondt2709 wants to merge 1 commit into
sondt2709 wants to merge 1 commit into
Conversation
The aggregate device was created without the tap list, then the tap was added afterward via AudioObjectSetPropertyData with flat UID strings. This delivers all-zero (silent) audio on macOS 26 Tahoe. Restructure to include kAudioAggregateDeviceTapListKey with structured sub-tap dictionaries (kAudioSubTapUIDKey, kAudioSubTapDriftCompensationKey) directly in the AudioHardwareCreateAggregateDevice creation dictionary, matching Apple's reference implementation. Constraint: Must remain compatible with macOS 14.2+ where the tap API was introduced Rejected: Keep post-creation property-set approach | silently fails on macOS 26, not used by reference implementations Confidence: high Scope-risk: narrow Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
makeusabrew
reviewed
May 22, 2026
| kAudioAggregateDeviceNameKey: "audiotee-aggregate-device", | ||
| kAudioAggregateDeviceUIDKey: uid, | ||
| kAudioAggregateDeviceTapListKey: tapList, | ||
| kAudioAggregateDeviceTapAutoStartKey: false, |
Owner
There was a problem hiding this comment.
Thanks @sondt2709! Can you confirm the addition of this kAudioAggregateDeviceTapAutoStartKey: false setting has no adverse effects?
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
2 participants
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.
Summary
kAudioAggregateDeviceTapListKeydirectly in the creation dictionary, using structured sub-tap dictionaries (kAudioSubTapUIDKey,kAudioSubTapDriftCompensationKey)addTapToAggregateDevice()step that usedAudioObjectSetPropertyDatawith flat UID string arraysCATapDescription.uuidinstead of queryingkAudioTapPropertyUIDafter creationProblem: On macOS 26 (Tahoe), the previous approach of adding the tap to the aggregate device after creation via
AudioObjectSetPropertyDatasilently fails — the tap creates successfully, the IO proc runs at the correct rate, but all audio buffers contain zeros. This matches a known pattern where Apple's reference implementations (sudara's gist, AudioCap) include the tap list in the aggregate device creation dictionary.Scope: Single file change to
AudioTapManager.swift. No public API changes. Should remain compatible with macOS 14.2+ where the tap API was introduced.Test plan
swift build -c releasecompiles without errorsaudiotee --stereowhile playing audio → captured PCM contains non-zero samplesaudiotee --sample-rate 48000 --stereo | ffmpeg -f s16le -ar 48000 -ac 2 -i pipe:0 test.mp3→ output MP3 has audible sound🤖 Generated with Claude Code