Skip to content

feat(audio): record several playback devices as separate clip tracks - #89

Open
vxnsin wants to merge 1 commit into
FTHR-Community:windowsfrom
vxnsin:feat/audio-device-tracks
Open

vxnsin wants to merge 1 commit into
FTHR-Community:windowsfrom
vxnsin:feat/audio-device-tracks

Conversation

@vxnsin

@vxnsin vxnsin commented Oct 18, 2026

Copy link
Copy Markdown

What does this PR do?

Adds a "Record" choice to Settings > Audio: one device (as before), each program as its own track, or several playback devices as separate named tracks in the clip.

Why?

With a hardware mixer (for example a RODECaster with Chat, Game and Music outputs) only one playback device could be recorded, and per-program tracks were tied to the "separate system and microphone tracks" switch. Several devices as their own tracks lets the clip editor balance each source on its own.

Changes

  • Settings > Audio: new "Record" selector. For "Several devices" you pick a playback device, name the track and add it (up to 4). The playback device picker is only shown for "One device".
  • Engine: each added device is captured with WASAPI loopback and written as its own named track plus a manifest entry. Idle devices are padded with silence so a device that goes quiet stays on the timeline. The combined Default Mix is left out in this mode.
  • The muxer no longer requires the Default Mix to be the first track. An unavailable system endpoint used to fail the whole save (Error 015); now only that track is dropped.
  • Two new engine launch arguments: 26 (device list as name;endpoint|...) and 27 (per-program flag, defaults to the separated-mode value). Names are limited to the character set the audio manifest accepts.
  • Clip track limit and manifest reader grow from 10 to 14 sources.
  • Saved choice (audio_source_mode) wins; older settings derive it from the per-program switch / separated mode, so existing setups behave as before.

Testing

  • Ran QT_QPA_PLATFORM=offscreen pytest tests/ — all pass except test_sftp_provider (upload bundle not present in a source checkout)
  • Tested manually on Windows
  • Native suite (FTHRclips_tests): 22624 checks pass, including new parser/limit tests.
  • Saved clips in all three modes on an AMD GPU: "several devices" produced the expected named tracks (a device with no audio is skipped with a log line), "each program" and "one device" kept their previous tracks.

Notes

  • The AMD fix for odd window sizes lives in its own PR and is not part of this branch.
  • A device that cannot be opened (for example one held exclusively by another app) is logged and skipped; the clip is still saved with the remaining tracks.

Screenshots

One device:

One device

Each program as its own track:

Each program

Several devices as separate tracks:

Several devices

Settings > Audio gets a "Record" choice: one device (as before), each
program as its own track, or several playback devices as separate tracks.

For several devices, every added device (for example a mixer's Chat, Game
and Music outputs) is captured by WASAPI loopback and saved as its own named
track in the clip and its audio manifest, so the clip editor can adjust each
one. Idle devices are padded with silence so a device that goes quiet stays
on the timeline. The combined Default Mix is left out in this mode.

The muxer no longer requires the Default Mix to be the first track: an
unavailable system endpoint used to fail the whole save (Error 015) and now
only drops that track.

Engine launch arguments 26 (device list) and 27 (per-program flag) are new;
the clip track limit and the manifest reader grow from 10 to 14 sources.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant