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
co-authored by Claude Opus 5
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.5 → 1.0.
module constant, so it is tunable per node. See the setting in config.py for
why the default moved 1.0 → 3.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