Adaptive OPUS_SET_PACKET_LOSS_PERC for OPUS64 instead of the hardcoded 35

[mcfnord]

🤖 AI: Every OPUS64 encoder in Jamulus is configured with OPUS_SET_PACKET_LOSS_PERC(35) (src/client.cpp:119, src/server.cpp:128) whether or not the connection is losing anything. The comment there - "for 64 samples frame size we have to adjust the PLC behavior to avoid loud artifacts" - is correct, and the constant is doing real work. It is also being paid for by everyone, including people losing nothing.

The setting tells Opus how much of a fixed bit budget to spend making each frame survivable when its neighbours go missing. Pinned at 35, it spends that on every connection. Jamulus is used to play music, so the measurements below are music: 21 recordings of contrasting character, the codec driven at Jamulus's own OPUS64 settings, scored with ViSQOL in audio mode - an objective estimator of MOS, the 1-to-5 listening-quality scale - with segmental SNR as the independent cross-check.

What the constant costs a clean connection. At the shipped 35-byte tier, plc=35 costs ViSQOL MOS against plc=0 on 20 of the 21 recordings, median 0.014, up to 0.056 on a solo guitar. Small, real - and a property of the recording that nothing at the sender can estimate: the two percussion-labelled recordings span 0.002 to 0.037, the two guitar-labelled ones sit at opposite ends of the whole range, and the per-recording cost correlates with no signal-domain measure tried (rank correlation -0.12 against the decoded-waveform cost of the same setting). An earlier measurement on a single piano recording had found no cost at all - the four loss_perc values within 0.006 and 35 not even lowest - and across the corpus that file turned out to be the single exception. Controls: identical input scores 4.732, the audio-mode ceiling; the score rises monotonically across the shipped 24/35/73-byte tiers; and all 44 clean p0/p35 arms reproduce bit-identically (same encoder checksums) when re-run.

What it buys under loss.

uniform loss, mean burst 1	median benefit, plc35 - plc0	share of the damage recovered	recovered at mean burst 32
2%	+0.23	83%	5%
5%	+0.48	87%	16%
10%	+0.80	86%	23%

ViSQOL, medians across the music recordings (11 at loss 2 and 10, 21 at loss 5). Two things the table compresses. The benefit is roughly proportional to the damage: at burst 1, plc=35 gives back 83-87% of whatever quality the loss destroyed, on nearly every recording. And it does not survive bursts: real paths lose in runs, and by mean burst 32 the recovered share has collapsed to 5-23% - at 2% loss the benefit is actually negative on 6 of the 11 recordings measured there. So the constant earns its keep on genuinely bad connections, pays a small unpredictable tax on clean ones, and past long-burst loss stops helping at all. No single value is right for all three regimes, which is why retuning the constant is not the fix.

One honesty note about the instrument. Segmental SNR over the same arms agrees with every direction above but puts the recovered share at 47% where ViSQOL puts 86 (10% loss, burst 1, same recordings). Concealment evidently sounds better than it matches the waveform, and how much better is a question no amount of scoring settles without ears.

What could drive the ctl. The obvious input is the one Jamulus already computes: CNetBuf::Get() returns false exactly when the decoder must conceal, and CChannel::GetData turns that into GS_BUFFER_UNDERRUN. Measured, that counter cannot support this ctl on its own, because it reports the event and not the cause. Real client against real server, 120 s per arm, one network condition injected at a time:

arm	on the wire	concealment reads	sequence-loss reads
clean	0 dropped	0.36%	0.00%
5% loss (netem)	4.92% dropped, 4.90% by capture	5.39%	4.97%
jitter, no loss (20 ms +/- 3 ms)	0 dropped, 52.7% arriving out of order	4.21%	0.15%
client frozen mid-session (SIGSTOP, 12 s)	nothing sent	42.6% in that window	+0

Concealment reads 5.39 on a link losing 5% and 4.21 on a link losing nothing - it cannot tell them apart - and a client that merely stops sending books 42.6%. The second column comes from a counter on the one-byte sequence number every audio packet already carries when negotiated (channel.cpp:207): received and missing counted against a running span maximum, so a late arrival cancels the gap it opened and reordering never books as loss - 0.15% under 52.7% reorder - and a silent client adds nothing because its sequence stream has no gap. It matches the wire to within 0.07 points. That counter is not hypothetical: it runs in this fork's fleet binary today, in the same per-window record as the concealment count, so both quantities are available side by side.

Direction needs no protocol to resolve: each end counts the stream it receives, so uplink and downlink are separate measurements by construction. What the pair of counters adds is a distinction a single one cannot make: a struggling client - stalled callbacks, frozen process - produces concealment on the server with zero sequence loss, and from the server that used to be indistinguishable from a lossy uplink. Whether the ctl should follow concealment (the perceptual event, whatever its cause) or sequence loss (the network's actual share of it) is a real design question, posed below.

The design problem, which is the reason for this post. Loss protection has come up before - #781 asked about XOR redundancy, and #3895 covers the raw-audio path this ctl does not touch - but adapting the protection Opus already ships is a different lever. The ctl sits on the sender's encoder; the loss is only visible at the receiver. Two shapes:

• Server-only. The server measures concealment on a client's uplink and uses it to set that client's downlink encoder. No protocol change, no client change, works against every client in the field today. It rests on the assumption that what the server measures on the uplink says something about the downlink - and the frozen-client row above is a measured case where an uplink reading has no network cause at all.
• Bidirectional. One new low-rate message carrying a one-byte concealment percentage in each direction, sent on change plus a keepalive, off the audio thread. Both directions then adapt on direct evidence instead of a proxy.

Deliberately conservative reading. Whatever the clean-side gain turns out to be worth, it applies to the download direction only in the server-only shape, to OPUS64 only, and only on paths clean enough to sit in the lowest bucket. Anything past a few percent concealment lands back on today's behaviour by design, as does every degenerate case: no completed window, a format change, a silent client. CBR is unchanged, so packet size and cadence do not move, and the jitter buffer is a separate subsystem that is not touched.

Where scrutiny would be most useful:

1. Is the uplink close enough to the downlink on real paths to justify the server-only shape at all - and if it is used, which input: concealment fires on jitter and client stalls where extra protection cannot reduce the concealment count (only make each concealment sound better), sequence loss fires only on what the wire actually dropped. The frozen-client row is the case where the two answers diverge completely.
2. The clean-side cost varies 0.002-0.056 across music content and correlates with nothing measurable at the sender - so the gain from lowering protection on clean connections is real but unpredictable per user. Is that gain worth pursuing, or is the whole value of adapting the freedom to raise protection on bad connections rather than lower it on good ones?
3. Is a window of a couple of seconds, with an immediate step up in protection and a delayed step down, the right dynamics - or is any movement at all unwelcome in a live mix?
4. Is there a reason not to touch this that is not in the list above?

Everything above is reproducible and the harness is nothing exotic: opus_custom driven at Jamulus's own OPUS64 settings for the codec numbers, scored with ViSQOL and segmental SNR as labelled; and for the counter, two network namespaces on a veth pair with tc netem shaping one direction at a time while both ends are polled over JSON-RPC. Corrections to the method, or tests worth adding, are more useful here than agreement - particularly on which instrument to trust where they disagree, which no amount of further scoring settles without ears.

---

🤖 This message was written by AI and reviewed by @mcfnord.

[pljones]

Server versions are slow to change, so I wouldn't think about a solution that relies on Server-side changes.

1. A new Server can be "better" than an old Server but it cannot exclude old Clients
2. New Clients must be able to access old Servers without degradation (over what they get now).

So any solution that requires either a Server-only or bi-directional change probably will be of limited impact.

[mcfnord]

Old servers would ignore the new client feedback, so it's backward-compatible.

[pljones]

Yes - but of limited impact

Directory	# servers	>= 3.12.4	of which JAMFAN	without JAMFAN
choral	18	6	0
classical	32	4	0
jazz	53	25	12	(41 13)
rock	41	17	11	(30 6)
asia	19	2	0
anygenre2	38	12	2	(36 10)
anygenre1	106	31	13	(93 18)

Unlike raw audio, which is clearly a new feature, this is small improvement in corner case, as far as I can see.