AUHAL input render returns silent buffers from BlackHole while another process reads real signal simultaneously

[ampliobeta]

AUHAL input render returns silent buffers from BlackHole while another process reads real signal simultaneously

I'm capturing audio from BlackHole 2ch using a manually-instantiated kAudioUnitSubType_HALOutput AudioUnit (input-only, output disabled), following the standard AUHAL input-capture pattern (CAPlayThrough-style: AudioOutputUnitStart + AudioUnitRender inside the input callback).

Setup:

• macOS Tahoe 26.6
• BlackHole 2ch (installed via Homebrew)
• System output set to BlackHole 2ch
• Audio Unit configured: input enabled on element 1, output disabled on element 0, device set via kAudioOutputUnitProperty_CurrentDevice, client format forced to non-interleaved Float32 stereo (matching BlackHole's reported sample rate)

Symptom:
AudioUnitRender returns noErr every callback, with correctly-shaped buffers (right channel count, right byte size, ioActionFlags = 0, no silence flag set) — but every sample is exactly 0.0.

The key clue: at the exact same moment, with the exact same audio playing, a separate process (QuickTime Player's "New Audio Recording" using BlackHole 2ch as input) shows a live, moving level meter — proving real signal is present in BlackHole at that instant. My own render call, on the same device, reads nothing.

What I've ruled out:

• Format mismatch (confirmed via kAudioUnitProperty_StreamFormat readback — matches BlackHole's actual format)
• Interleaved vs. non-interleaved buffer layout (explicitly forced non-interleaved)
• Device assignment failure (confirmed via property readback — correct device ID is set)
• Volume/gain issue (BlackHole's own output volume confirmed at max in Audio MIDI Setup)
• Downstream playback chain (verified separately — AVAudioEngine mixer/output formats are valid and correctly connected)

Question: Is there a known requirement for a second simultaneous AUHAL client on BlackHole that differs from a single-client setup — e.g., a specific kAudioUnitProperty_ShouldAllocateBuffer setting, buffer frame size negotiation, or IOProc registration order — that would cause AudioUnitRender to succeed structurally while returning silent data, even though another process is reading real audio from the same device concurrently?

--- thanks

[devinroth]

Most likely a microphone permissions issue. Devin

…

On Aug 4, 2026 at 8:08 PM -0500, ampliobeta ***@***.***>, wrote: AUHAL input render returns silent buffers from BlackHole while another process reads real signal simultaneously I'm capturing audio from BlackHole 2ch using a manually-instantiated kAudioUnitSubType_HALOutput AudioUnit (input-only, output disabled), following the standard AUHAL input-capture pattern (CAPlayThrough-style: AudioOutputUnitStart + AudioUnitRender inside the input callback). Setup: • macOS Tahoe 26.6 • BlackHole 2ch (installed via Homebrew) • System output set to BlackHole 2ch • Audio Unit configured: input enabled on element 1, output disabled on element 0, device set via kAudioOutputUnitProperty_CurrentDevice, client format forced to non-interleaved Float32 stereo (matching BlackHole's reported sample rate) Symptom: AudioUnitRender returns noErr every callback, with correctly-shaped buffers (right channel count, right byte size, ioActionFlags = 0, no silence flag set) — but every sample is exactly 0.0. The key clue: at the exact same moment, with the exact same audio playing, a separate process (QuickTime Player's "New Audio Recording" using BlackHole 2ch as input) shows a live, moving level meter — proving real signal is present in BlackHole at that instant. My own render call, on the same device, reads nothing. What I've ruled out: • Format mismatch (confirmed via kAudioUnitProperty_StreamFormat readback — matches BlackHole's actual format) • Interleaved vs. non-interleaved buffer layout (explicitly forced non-interleaved) • Device assignment failure (confirmed via property readback — correct device ID is set) • Volume/gain issue (BlackHole's own output volume confirmed at max in Audio MIDI Setup) • Downstream playback chain (verified separately — AVAudioEngine mixer/output formats are valid and correctly connected) Question: Is there a known requirement for a second simultaneous AUHAL client on BlackHole that differs from a single-client setup — e.g., a specific kAudioUnitProperty_ShouldAllocateBuffer setting, buffer frame size negotiation, or IOProc registration order — that would cause AudioUnitRender to succeed structurally while returning silent data, even though another process is reading real audio from the same device concurrently? --- thanks — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>