[Feature Proposal] Extensible audio providers for Unity Recorder (FMOD prototype)

Audio & Video
, , ,
1

I would like to propose a small, middleware-independent audio input extension point for Unity Recorder.

Problem

Recorder 5.1.7 captures audio through Unity’s built-in audio renderer. In a Unity 6000.5 project whose audio is driven by FMOD, enabling Include Audio can crash the Unity Editor instead of recording the FMOD mix. Even when a native crash is avoided, Recorder has no supported way to supply PCM from a third-party audio engine together with that engine’s real sample rate and channel count.

Bridging FMOD through an AudioSource or OnAudioFilterRead is not a good general solution: it duplicates routing, changes the signal path, and still couples Recorder to Unity’s audio timing.

Proposed Recorder API

The prototype adds a public editor-only IRecorderAudioInputProvider contract and a TypeCache registry with stable provider IDs. Recorder settings expose an Audio Source selector. Existing presets remain backward-compatible and resolve to a built-in provider that preserves current behavior.

Provider sample rate and channel count flow through RecordingContext into the existing Core, ProRes, and WAV encoders. Unsupported layouts and concurrent recordings with different audio sources are rejected before recording starts. The Recorder core has no FMOD reference.

FMOD proof of concept

The optional sample contains two providers:

  1. FMOD Master taps the existing FMODUnity.RuntimeManager master channel group with a pass-through DSP and transfers interleaved float PCM through a preallocated SPSC ring buffer.
  2. FMOD NRT (Constant FPS) owns a separate FMOD Studio system configured for non-realtime synchronous updates. It pumps the system until the exact rationally scheduled PCM frame count is available, so audio duration follows Recorder’s constant-FPS frame count even when rendering is slower than realtime.

The NRT system is deliberately separate from RuntimeManager; events intended for offline recording are created through a small runtime facade. Realtime StudioEventEmitter instances are not silently mirrored.

Validation

  • Unity 6000.5.9f1, Recorder 5.1.7, FMOD for Unity 2.03.20.
  • Full EditMode suite: 38/38.
  • Sequential 48 kHz stereo WAV captures with non-zero PCM.
  • H.264 MP4 with an importable audio track.
  • 10-minute realtime capture at 60 FPS.
  • Valid WAV and controlled diagnostics after a deliberate 5.5-second main-thread stall.
  • NRT test: 90 frames at 30 FPS generated exactly 3.000000 seconds of PCM while wall-clock rendering took 5.520168 seconds.

Code, design notes, sample usage, and validation details:

I suggest reviewing this in two independent parts:

  1. A core-only Recorder change containing the generic provider API, built-in compatibility implementation, UI, metadata propagation, validation, and tests.
  2. The FMOD realtime/NRT sample as optional reference material, only if Unity wants to carry a middleware example.

Would the Recorder team be interested in this extension point? If so, which official repository or contribution channel should receive the core-only patch? I have not opened a pull request because the package metadata points to Unity’s internal Recorder repository and I could not find a current official public upstream repository.

2

Thank you so much for the time taken to come up with the proposal, its quite rare we get such a well researched and implemented feature request! Internally we have this logged but can not speak to timelines. We do recognise this as a valid usecase and hope to be able to support capturing 3rd party audio input for recorder at some point.

Further to that, we actually have Root Outputs as part of the Scriptable Audio Pipeline that we have started releasing this year. It is a scriptable entry point right at the end of the built in Unity Audio system, so it doesn’t take part in our internal mixing graph but is added to the final output sent to the device - and Recorder is modeled as a “fake” device so anything you output in Root Outputs will end up in Recorder.

This is the way we are hoping that 3rd parties will begin to integrate their audio systems with Unity. If this happens then recorder is essentially “for free” with integrations going through Root Outputs.

Once again thanks for the great proposal.