fix(alarm): cap the ring at the configured volume instead of the device max
Build & Deploy PluriWave / Análisis de código (push) Successful in 35s
Build & Deploy PluriWave / Build APK + AAB release (push) Successful in 1m48s

The ring-scoped media override forced STREAM_MUSIC to the hardware
maximum, so the alarm's configured percentage was applied on top of a
maxed speaker: "50%" meant 50% of the phone's absolute maximum and
the fade rode against that ceiling, far louder than the device-
relative level users were used to. On-device logcat also showed the
just_audio player emitting one buffer at volume 1.0 before the 5%
pre-start took effect, a full-scale click on the maxed stream.

The stream is now capped at the alarm's configured volume (still
independent of the device's own level, so it rings at device-volume
0), and the player ramps from ~5% up to its full range under that
cap. Perceived peak is the configured fraction of the device maximum,
reached gradually; the opening click drops to the configured fraction
instead of full scale.
This commit is contained in:
2026-07-11 22:48:56 +02:00
parent 2c28f1696a
commit 5291221fc8
3 changed files with 20 additions and 5 deletions
+7 -1
View File
@@ -111,7 +111,13 @@ class _PantallaAlarmaSonandoState extends State<PantallaAlarmaSonando> {
void _iniciarFadeIn() {
_fadeInTimer?.cancel();
final volumenObjetivo = widget.alarma.volumen.clamp(0.0, 1.0);
// The media stream is already capped at the alarm's configured volume
// (forzarVolumenMediaParaAlarma), so the player ramps up to its OWN full
// range under that cap. Perceived peak = configured% of the device max,
// reached gradually from ~5% of the cap; ramping the player to
// widget.alarma.volumen here would double-attenuate (configured x
// configured) and undershoot the level the user chose.
const volumenObjetivo = 1.0;
final inicio = _volumenInicialFadeIn.clamp(0.0, volumenObjetivo);
final segundosFade = widget.alarma.fadeInSegundos.clamp(0, 60);
if (segundosFade <= 0 || volumenObjetivo <= inicio) {