Software audio tap crashes on multichannel PCM when AVAudioFormat returns nil

[dlev02]

What happened?

A TestFlight crash report came in from Prism. The app was using AetherEngine 6.1.3.

The crash is fully symbolicated and lands in the software-path audio tap:

Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value
AudioTapPCMConverter.convert(_:) (AudioTapPCMConverter.swift:30)
AetherEngine.installSoftwareTapSink(controller:)
SoftwarePlaybackHost.runDemuxLoop(...)

AudioTapPCMConverter creates its input format with the channel-count-only AVAudioFormat initializer and force-unwraps the result. On macOS that initializer returns nil for interleaved Float32 input with 3–8 channels at normal sample rates, including 48 kHz/6-channel PCM. That matches the software decoder's supported multichannel output.

This is only fatal while an audio-tap consumer is active, such as soundtrack recognition or live transcription. Playback without a tap does not run this converter. The same force unwrap is still present on current main.

Steps to reproduce

1. Create interleaved Float32 PCM with more than two channels, for example 48 kHz/6-channel.
2. Install an audio tap while the software playback path is active.
3. Deliver the decoded CMSampleBuffer to AudioTapPCMConverter.convert(_:).
4. AVAudioFormat(commonFormat:sampleRate:channels:interleaved:) returns nil, and line 30 traps on the force unwrap.

The Foundation behavior can also be reproduced directly without the original media file:

let format = AVAudioFormat(
    commonFormat: .pcmFormatFloat32,
    sampleRate: 48_000,
    channels: 6,
    interleaved: true
)
// format == nil

AetherEngine version or commit SHA

6.1.3 / 343bcba (confirmed unchanged on current main)

Host app

Custom / my own integration

Platform

macOS

OS version

macOS 27.0

Device / chip

Apple Silicon Mac (ARM64; exact model not included in the TestFlight report)

Playback path

Software (dav1d) host

Source media (for playback bugs)

The original media file is not available. The crash is in the decoded interleaved Float32 PCM path and is directly reproducible with 48 kHz/6-channel PCM.

Error codes / log lines

Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value
AudioTapPCMConverter.swift:30

Anything else

A narrow fix would be to reuse AetherEngine's existing channel-layout mapping and remove the force unwrap:

var streamDescription = asbd
guard let channelLayout = AVAudioChannelLayout(
    layoutTag: audioChannelLayoutTag(for: Int32(asbd.mChannelsPerFrame))
),
let inFormat = AVAudioFormat(
    streamDescription: &streamDescription,
    channelLayout: channelLayout
) else {
    return []
}

AudioDecoder already uses the same audioChannelLayoutTag(for:) mapping when it creates these sample buffers, so this should preserve the intended 3.0/5.1/7.1 layout without changing routing or public API.

The existing AudioTapPCMConverterTests.makeSample helper already accepts a channel count, so one 5.1 conversion case should cover the regression without new test infrastructure.

I have not included the TestFlight crash file because it contains unrelated user/session metadata.

[superuser404notfound]

Fixed and released in 6.34.0 (9470c87a, merged as 5b56848b).

The mechanism in the report is exactly right, and it reproduces here: the same trap, the same line, from a real session rather than a fixture buffer.

Two corrections to the framing, both worth having.

It is not macOS-specific. AVAudioFormat(commonFormat:sampleRate:channels:interleaved:) returns nil for every channel count above 2 on every platform. Measured 3 through 8, both interleaving variants:

ch=1 ok    ch=3 nil    ch=6 nil
ch=2 ok    ch=4 nil    ch=8 nil

So tvOS and iOS hit this too as soon as the software path runs there with a tap installed.

The root cause sits one level below the force unwrap. AudioDecoder.createFormatDescription already attaches a correct AudioChannelLayout to the format description. The converter discarded it and re-derived a format from the bare channel count, so the information it needed was in the object the function already held. It reads it back from there now, with the engine's own mapping as a fallback for a description that carries none. And since the decoder resamples to the source channel count without downmixing, this was never a race: the first audio buffer, every time.

Two things came out from underneath it that may matter on the Prism side.

Some layouts convert to digital silence with no error set. Measured: 4-channel Quadraphonic and every DiscreteInOrder layout. At a tap consumer that is indistinguishable from a muted source, so if soundtrack recognition or transcription has ever gone quiet on 4-channel material rather than crashing, that is a candidate. The converter now pushes one full-scale buffer through each new converter and folds the channels itself when the answer is silence. The check sits on the measured behaviour rather than on a list of layouts Apple currently mixes.

The software sink had no headless driver at all, which is how a guaranteed first-buffer trap shipped in 6.1.3 and survived to main: both existing audiotap modes drive their readers directly, and that sink only exists inside a real session. aetherctl audiotap --software now loads a source through the whole engine and installs the tap through the public API. Exit 3 covers both no buffers and buffers of silence.

Separately, checking whether that missing mixdown also reached the renderer turned up an unrelated defect in the same subsystem, #401: the layout stamped on software-path audio did not describe the order the resampler wrote, so on 7.1 every channel was misplaced and the LFE was rendered hard left at full gain. Also fixed in 6.34.0. It affects playback rather than the tap, so it is worth a listen on Prism's multichannel material if any of it goes through the software path.

Thanks for the crash report, and for including the symbolicated frames and a standalone repro of the Foundation behaviour. That is what made this a measurement instead of an argument. Leaving this open for a retest against 6.34.0.