Repository navigation
Conversation
Browser media elements cap volume at 1, but live channels here carry MP2 audio that the page cannot decode natively: it goes through the PCM/WebAudio path, which already owns a GainNode feeding the speakers. Loudness above unity therefore only needs gain on that node plus a limiter, because the extra gain would otherwise clip and clipping is audible as crackle on speech. The PCM player gains a boost factor composed with volume (1x..6x, +15.6dB at the ceiling) and a limiter after the gain stage (threshold -6dB, ratio 12:1, 3ms attack) so peaks are compressed instead of clipped. The level is held by the playback controller rather than the player, because the player is created lazily and rebuilt on every audio recovery. Both volume controls drive the same two ranges: the lower half of the slider is 0..100% element volume, the upper half is the gain multiplier up to 6x, and the on-picture vertical gesture uses the identical mapping so it can continue past 100% too. A readout shows the applied level (e.g. 250%) while dragging, and the gesture indicator shows the same percentage with the bar split 50/50 between the two ranges.
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.
为什么
浏览器对
<audio>/<video>的volume有硬上限 1，而这里的直播频道是 MP2 音频，网页不能原生解码，走的是 PCM 软解 + WebAudio 排程那条路——那条路上播放器本来就自己持有GainNode直接喂扬声器。也就是说：想超过 100%，不需要碰元素音量，只要在那个
GainNode上给增益。但增益超过 1 会削波，削波在语音上是可闻的"爆音"，所以增益级后面必须跟一个限幅器，把峰值压住而不是切掉。改了什么
pcm-audio-player.tsboost（1..6）与setBoost()，与volume是相乘关系；gainNode之后串一个DynamicsCompressorNode（threshold -6dB、ratio 12:1、attack 3ms、release 250ms）当限幅器；iOS 的 MediaStream 旁路和默认输出两条路由都接在限幅器后面；currentGain()，让所有写增益的地方（updateGain、cancelChain的淡出）走同一处计算。此前cancelChain(smooth)淡出后把增益写回volume，把倍数冲掉——直播中重同步很频繁，这也是"调了没变大"的原因之一；audioElement.volume仍然钳到 1（元素上限），超出的部分已经在增益级上给过了。playback-controller.tsensurePCMPlayer()创建后重新应用一次。UI（
player-controls.tsx、use-player-touch-gestures.ts、player-gesture-overlay.tsx）levelToPos/posToLevel），所以滑过 100% 之后继续进入增益区；player-storage.ts说明
setVolumeBoost在不具备增益级的后端上是可选方法（no-op）。