A flaw in how steady tones survive a lost packet, found while measuring the engine, and fixed.
Measuring the engine turned up something odd.
What we heard in the numbers
We were checking how well speech survives a lost packet, which is routine. Then we tried the same test with a ringing tone, and the output came back five to seven times louder than it went in. Loud enough to clip.
Speech hardly did it. A steady tone did it reliably: ringing, a dial tone, a single held note.
The cause
A modern speech codec saves space by describing each moment of sound in terms of the moment before. For a perfectly steady tone, that works extremely well: "the same again" is nearly the whole message.
But if a packet is lost, the listener's decoder has to guess, and then keeps building on its guess. With a pure tone, a small error can feed on itself and grow instead of fading.
It was not our engine's doing. The same weakness was there before, with the older software, and a browser on the other end would do the same. Nobody had noticed because nobody listens closely to a ringing tone on a bad line.
Two fixes
- Kahevo now recognizes a steady tone as it happens, within about a tenth of a second, and sends it in a way that does not lean on earlier packets. A lost packet becomes a short dip and nothing more.
- In the engine, two limits inside the codec's encoder are tightened so it cannot lean that hard in the first place.
| Test, with packets being lost | Before | After |
|---|---|---|
| Tones played over three times too loud | Thousands of moments | None |
| Samples loud enough to clip | Millions | None |
| Speech after a lost packet | Baseline | Same or better |
The careful part
Every change was checked against ordinary speech, because a fix for tones that hurt voices would be a bad trade. Speech came out the same or slightly better at every bitrate we tried.
Why tell you
Because this is what "in testing" means. Not glamorous. But nobody should get an earful for waiting on a ring.