voip/mlow: 1:1 audio from WhatsApp Desktop is silent - the decoder drops every 120ms frame

[Bot-Dev-RPA]

The comment at wacore/src/voip/mlow/decoder.rs:125 asks whether real peers ever emit active out-of-operating-point frames in 1:1 calls:

the warn names the offending dimension so a live capture shows whether real peers ever emit active out-of-point frames in 1:1 calls

Answer from a live account: yes, WhatsApp Desktop does, routinely, and the call is silent as a result.

Symptom

Any 1:1 call where the media peer is the Windows desktop client (platform="windows", version 2.3000.1043850389.262501) connects normally and carries no audio from that peer. The same build on the same account has clean two-way audio when the peer is the Android phone.

Evidence

mlow: dropping out-of-operating-point frame #1 (frame_ms=120, TOC 0x58);
the 1:1 decoder is 16kHz / low_rate=0 / 60ms only

Correlation across five calls on one account:

peer	direction	mlow drops	audio
Windows desktop :48@lid	inbound	#1, #100	silent
Windows desktop :48@lid	outbound	#1	silent
Windows desktop :48@lid	inbound	#1	silent
Android phone @lid	inbound	none	two-way, fine
Android phone @lid	outbound	none	(blocked by #1098)

Note the drop counter only logs on #1 and every 100th, so a lone "#1" is not one bad frame - it is the start of a run that then goes silent.

The desktop peer emits frame_ms=120 consistently (TOC 0x58). decode_frame takes the operating-point guard at decoder.rs:131 (toc.frame_ms != 60) and drops each one as a lost frame, so the whole stream is discarded.

Why it matters

WhatsApp Desktop is a normal thing for a contact to answer on, and there is no signal that the audio is being dropped rather than absent - the guard is a warn! on a sampled counter, so a consumer sees a connected call with silence.

Environment

7b26749d, voip feature, native runtime, 1:1 audio, callee/caller both real WhatsApp clients on one account (India).

Happy to capture raw payloads for a 120ms frame if that would help size the decoder work.

[jlucaso1]

@Bot-Dev-RPA thanks for the capture and for the TOC correlation table — that made this quick to place.

#1111 has a fix. The short version: a packet is not one unit of decode. The reference derives the loop count from the declared duration (num_frames = (packet_len_ms + 10) / 20) while the geometry inside each iteration is unchanged, so 20, 60 and 120 ms differ only in how many times the same decode repeats. decode_active_frame had the count hardcoded to 3. Driving it from the TOC admits 120 ms (and 20 ms) without touching the synthesis — 10 ms stays out, since it is the one duration that also halves the internal frame length and the subframe count.

So the answer to the question in the comment you quoted is a definite yes, and the decoder work it was sizing turned out to be a loop bound rather than a new code path.

It is validated against the C reference rather than by shape alone: a stream of real 120 ms packets decoded and compared to the reference decoder's own output for the same bytes, correlation 0.999894 at lag 0. Regenerating that fixture needs smpl_CreateCodec() before the first opus_encode, which is documented with the recipe.

Would you be willing to confirm on a live call against the Desktop peer before it is merged? The synthetic vector matches the reference, but yours is the only environment where the real client's stream can be heard end to end. The signal to look for is the dropping out-of-operating-point frame warning disappearing while audio arrives.

Unrelated to this, but since it came up in your report: the drop path is not the reason a call with an Android peer is silent — that one is #1098, which is still open.

[Bot-Dev-RPA]

@jlucaso1 I'll test this.