Independent volume selection causes temporary system volume spike

[prasta1]

Description

When making an independent volume selection, there is a temporary spike in system volume that can be startling — especially if youre not expecting it.

Steps to Reproduce

1. Make an independent volume selection
2. Observe the system volume behavior

Expected Behavior

Volume changes should be smooth and predictable, without any sudden spikes.

Actual Behavior

A brief but noticeable spike in system volume occurs during the selection, which can cause an unpleasant surprise.

Environment

• Device: MacBook Pro M5
• OS: macOS 27
• Recorded this ticket using Fluid Voice — it rocks! 🎙️

Additional Context

I saw the mention of it impacting system volume, but I wasnt expecting it to be that intense. The spike is brief but loud enough to catch you off guard. Would be great to either smooth out the transition or cap the peak during selection.

[altic-dev]

Did this get better with recent updates?

[postoso]

I checked current main after the recent audio changes. This behavior is still present: when Independent Volume is enabled, TranscriptionSoundPlayer saves the current output volume, calls setSystemVolume(desiredVolume) before playing the cue, and restores it after the cue duration.

I think the clean fix is to make this path strictly app-local and never write the Mac output volume:

• Remove the saved-volume, setter, and delayed restoration state.
• When the output scalar is readable and above a small mute threshold, set the player volume to min(1, desiredVolume / systemVolume).
• Suppress the cue at mute or near-zero output rather than changing the user's volume.
• If the output scalar cannot be read, fall back to the ordinary selected player volume.
• Keep the current cached-player and overlap behavior unchanged.

That compensates toward the selected cue level without affecting other audio. The current Mac output volume remains the ceiling, so the cue may still be quieter or inaudible at low volume or mute; I would make that limitation explicit in the setting copy rather than promising truly independent loudness.

I would also add pure policy tests for ordinary mode, compensation, the 1.0 cap, mute/near-zero suppression, an unavailable volume read, and out-of-range inputs, plus manually verify that the macOS volume HUD and continuous background audio never move.

I can open this as a focused PR for #522 if that direction sounds good.

[altic-dev]

I'd hold on to see if we can repro or if the OP @prasta1 responds. You can perhaps take it on then :)

Yeah output is smth i never looked into. Perhaps an issue is left

[prasta1]

I'd hold on to see if we can repro or if the OP @prasta1 responds. You can perhaps take it on then :)

Yeah output is smth i never looked into. Perhaps an issue is left

Will test later today. I'd left the setting off and haven't revisited. Thanks.

[prasta1]

@altic-dev just tested in 1.6.8 on MacOS 27.0 Beta (26A5388g), volume spike still present. Attempted to comment on this issue, with youtube playing in a tab, and still get a few milliseconds of high volume output from youtube, before it settles in.

[prasta1]

@altic-dev took a minute to do some finagling on version 1.6.9; the volume spike is still present, but the solution is 'Pause Media During Transcription'. I suspect this has more to do with Apple audio drivers than it does your application. Hope this helps; admittedly I don't fully understand what "Independent Volume" achieves, and if I were developing this, I would probably just yank the feature. But those are my unsolicited 'two cents'. Either way, keep up the great work, I love this application.

[postoso]

Thanks for testing both versions, @prasta1. That confirms the repro requested above, and the Pause Media workaround is useful.

The current implementation also gives us a direct app-side cause. With Independent Volume enabled, TranscriptionSoundPlayer temporarily sets the default output device's virtual main volume to the selected cue level, plays the cue, then restores the previous value. When the selected cue level is above the current output level, other audio using the same device can become louder during that window. That matches the brief YouTube spike you observed. The audio stack may affect the timing, but FluidVoice initiates the volume change.

The Pause Media setting avoids the audible spike in this case, but it does not remove that device-volume write. #867 removes the write from the transcription-cue path and uses app-local player gain instead. The tradeoff is that the cue can then never be louder than the current output level, so anyone keeping system audio low and relying on a louder cue gets a quieter one. Full reasoning is in the PR body.