fix(voice): honour the volume argument on Linux players#1548
Closed
m8ryx wants to merge 1 commit into
Closed
Conversation
playAudio() threads a volume multiplier through to buildArgs(), and the macOS afplay branch uses it, but every Linux candidate declares buildArgs: (file) => and silently discards it. Per-voice volume config and the notification API's volume field therefore do nothing on Linux — playback is always at system level, with no error. Map the multiplier (1.0 = normal, matching afplay -v) onto each player's own integer scale, read from their help output: ffplay -volume is 0..100, paplay --volume is linear 0..65536. A shared helper clamps and rounds; a non-finite or negative value falls back to normal rather than silencing playback. aplay has no volume-set option and is left alone. mpg123 scales with -f but its range was not verified here, so it is left alone rather than guessing a factor — both noted inline. No change to macOS behaviour.
Owner
|
Ported into source as-is, thank you. The per-player scaling with clamping is right, and the restraint on mpg123 (unverified range) and aplay (no flag) is the kind of honesty we want in the tree; both comments survive. Merge-back note: the public repo is generated from private source at release, so this closes as ported, with credit in the README. Ships with the next release. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
playAudio()accepts avolumemultiplier and threads it all the way through to the player:The macOS branch honours it:
Every Linux candidate declares
buildArgs: (file) => ...and silently discards the argument:So per-voice
volumein the config, and thevolumefield on the notification API, do nothing on Linux — playback is always at system level. There is no error; the value is simply dropped.FALLBACK_VOLUME = 1.0and per-voiceentry.volume ?? 1.0confirm the intended scale is a multiplier where 1.0 is normal, matching afplay's-v.Fix
Map that multiplier onto each player's own integer scale, taken from the tools' own help output:
A shared helper clamps and rounds:
A non-finite or negative value falls back to the player's normal level rather than silencing playback, which seemed the safer failure direction for a notification system.
Deliberately not changed
aplayhas no volume-set option — only--disable-softvol. Volume cannot be honoured on this fallback.mpg123scales with-f, but I could not verify its range on the machine I tested on, and guessing a factor risks making playback quieter for everyone else. Left as-is, with a comment marking it.Both are noted inline so the gap is visible rather than silent.
Verification
Flags confirmed present rather than assumed — a deliberately misspelled variant is rejected while the real one is accepted:
scaleVolumecovered by unit checks:1.0 → max,0.5 → half,0 → 0,2.0 → clamped (no amplification),NaN → normal,-1 → normal.bun build VoiceServer/voice.ts --target=buncompiles clean in place.No change to macOS behaviour — the
darwinbranch is untouched.