Raise tail pad to 3s so short transmissions are not clipped

The recording window is anchored to OP25 control-channel timestamps, but
the buffered audio lags those by roughly 1.5s. Trim logs across seven
calls measured the offset at 0.84-1.62s, consistently present.

At a 1.0s pad a short call closed its window before the voice arrived:
a 0.97s control-channel call closed at T+1.97 while voice started around
T+1.5, capturing ~0.4s of speech and cutting mid-word. Confirmed by a
0.57s file whose final 0.10s measured -12.2dB against its own -18.2dB
average - clipped speech, not a tail - and by two short calls that
logged no trim at all because no trailing silence remained.

Being generous is free here: trim_silence already strips trailing
silence back to the guard margin before upload, so long calls are
unaffected while short ones gain the window they need. Over-capture
costs nothing; under-capture loses words permanently.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Logan Cusano
2026-08-04 22:34:17 -04:00
parent 7c4a3f2f20
commit ceb2836371
4 changed files with 87 additions and 17 deletions
@@ -58,8 +58,13 @@ def _tail_pad() -> float:
edge (up to one poll late) plus encoder latency never clips the tail.
Read live from settings (env CALL_TAIL_PAD_SECONDS) rather than frozen into a
module constant, so it is tunable per node. See the setting for why the
default moved 0.51.0.
module constant, so it is tunable per node. See the setting in config.py for
why the default moved 1.03.0 (short calls' recording window was closing
before the ~1.5s grant→speech offset let voice audio even start).
Only the idle-timeout close path below uses this pad — the tgid_change and
tgid_change_unlogged paths close at an exact, already-known boundary (the
new grant's timestamp, or the same poll tick) and intentionally add none.
"""
return settings.call_tail_pad_seconds