[TheOrcDev]

Symptom

With Clips on and nothing recording or live, Studio → Soundboard says "Only you hear sounds until you record or go live." and sounds.press answers onAir: false. The press still lands in the Clips ring, so the next saved clip contains it at full bus gain. A streamer previewing pads between streams then posts a clip that has them.

Found on packaged 0.9.148 (Linux, VAAPI, Clips on). Not Linux-specific in the code.

Fix

Verified in code: start_session attached the soundboard with session_started(..., !replay_only). A buffer-only session still has a real audio bus, so voices mixed into the ring; on_air: false only hid that from sounds.press and the monitor copy.

Option A (matches the copy and docs/soundboard.md): skip session_started on replay_only. Idle presses stay monitor-only. Record and Go Live still attach with on_air: true and mix as before.

Tests

• Rust: a_replay_only_session_does_not_mix_idle_presses_into_the_bus — a press with no session_started is onAir: false and the session bus gets no Start; session_started(..., true) mixes once. cargo check -p videorc-backend --tests passed here. Linking the full backend test binary OOMs on this VM; CI should run cargo test -p videorc-backend sound_player.
• Existing desktop copy tests already assert the idle line for sessionOwnsTransport === false (a replayOnly session). They passed.
• Format check on the touched files passed.

Not verified here (needs a real app + audio)

• Clips on, idle press Ding, Save clip → clip has no Ding (padscan NCC as in the report's runs/c2).
• Record / Go Live still land a press once in the take / stream (pnpm smoke:soundboard / pnpm smoke:soundboard-fixture on a machine with capture).

  

Summary by CodeRabbit

• Bug Fixes
  • Buffer-only Clips sessions no longer activate the on-air ring when you press a soundboard control; those presses remain monitor-only. Record and Go Live sessions continue to connect the soundboard and report presses as on-air. This keeps soundboard behavior consistent with whether a session is recording or live.

[coderabbitai]

Caution

Review failed

The pull request is closed.

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: eea9e2cb-70ef-4143-b31f-03027d0c24cb

Commits

Reviewing files that changed from the base of the PR and between 4339122 and cb65966.

Files selected for processing: 4

• apps/desktop/src/renderer/src/components/studio/soundboard-section.tsx
• crates/videorc-backend/src/recording.rs
• crates/videorc-backend/src/session_audio.rs
• crates/videorc-backend/src/sound_player.rs

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 2 remain after this review.

Walkthrough

Replay-only buffer sessions no longer attach the soundboard bus. Sound presses made before attachment remain off-air and do not send a start command. Record and Go Live sessions attach the bus with on_air: true.

Changes: Soundboard session behavior

Layer / File(s)	Summary
Attachment policy and comments crates/videorc-backend/src/recording.rs, crates/videorc-backend/src/sound_player.rs, apps/desktop/src/renderer/src/components/studio/soundboard-section.tsx	Recording setup calls Soundboard::session_started only when replay_only is false, and passes true. Comments describe buffer-only Clips presses as staying off the ring.
Press behavior test crates/videorc-backend/src/session_audio.rs, crates/videorc-backend/src/sound_player.rs	A test-only bus helper counts start commands and acknowledges them as on-air. The test checks that a press before attachment is off-air and sends no start, while a press after live bus attachment is on-air.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• TheOrcDev/videorc#752: Adds the soundboard session-bus path that this change adjusts for replay-only sessions.
• TheOrcDev/videorc#743: Introduces the soundboard mixer, session bus, playback state, and recording integration modified by this change.
• TheOrcDev/videorc#694: Introduces buffer-only Clips sessions and the replayOnly state used by this change.

Merge Risk: Minimal · up to cb659

The attachment change has no established blocking defect. Saved-clip behavior still warrants validation on a machine that can run the audio checks.

Pre-merge checks: 4 · 1

Failed checks: 1 inconclusive

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 3 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the primary change: preventing idle soundboard pad presses from being included in Clips.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 3 files. (1 skipped: 1 too large.)

Resolution

Write docstrings for the functions missing them to satisfy the coverage threshold.

Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[TheOrcDev]

Verified on real Linux hardware (ogre, Intel VAAPI, Clips on)

Build: local integration of this branch + #817 + #818 on origin/main 4339122 (release backend, production renderer). Mic Off so any press would be the only audio.

• Idle presses stay out of clips: Clips buffer-only session running, sounds.press Ding, then Boom 2 s later (onAir: false for both), clip.mark 3 s later. Clip (30.0 s, H.264 + AAC): peak −inf dB, no Ding, no Boom. The monitor null sink captured both presses at the same time (peak −2.1 dB; Ding ~1.0 s, Boom ~2.8–5.0 s), so the streamer still hears them.
• On-air presses still land, once: Record, Ding + Boom (onAir: true), clip.mark mid-recording, Stop. Recording (62.5 s): one sound burst at 60.86–61.17 s, silence elsewhere. Mid-recording clip (30.0 s): the same burst at 28.86–29.17 s (the ring rides the recording and keeps on-air sounds). After Stop, the buffer-only ring re-armed (Running replay session).

CI fix pushed (cb65966)

Linux gate clippy failed on collapsible_if in recording.rs (if !replay_only { if let … }). Now a let-chain (edition 2024); cargo clippy -p videorc-backend -- -D warnings -A dead_code … is clean locally and the Linux gate passes. The macOS Rust and Windows jobs also fail or time out on main (#813).