Skip to content

Add server-initiated-pcm-24bit scenario with end-to-end test (#60)#73

Open
balloob wants to merge 1 commit into
mainfrom
claude/conformance-24bit-pcm-clean
Open

Add server-initiated-pcm-24bit scenario with end-to-end test (#60)#73
balloob wants to merge 1 commit into
mainfrom
claude/conformance-24bit-pcm-clean

Conversation

@balloob
Copy link
Copy Markdown
Collaborator

@balloob balloob commented May 27, 2026

Summary

  • Adds the server-initiated-pcm-24bit scenario from Sendspin/conformance#60 with a real end-to-end test through the aiosendspin server and client adapters
  • Reuses the existing audio-pcm verification mode — no new capability machinery
  • Wire format is 24-bit packed (3-byte LE, two's complement); the float-domain PCM hash matches the original 16-bit fixture, so audio-pcm comparison works without tolerance

Why this shape

The aiosendspin SDK ingests PyAV-compatible samples, and PyAV does not have a packed-s24 sample format. Feeding raw 3-byte/sample input to prepare_audio would fail inside PyAV with "got N bytes; need 4N/3 bytes". So the server adapter feeds 32-bit source PCM with AudioFormat(bit_depth=32) and lets the SDK's existing s32→s24 path produce the 24-bit packed wire format the client negotiates.

Per-SDK impact

  • aiosendspinaiosendspin: passes
  • Other client adapters that have not yet hardcoded the new scenario_id and matching SupportedAudioFormat(bit_depth=24) will fail their cases, surfacing the per-SDK 24-bit decode gap the audit identified (notably sendspin-go has no 24-bit code path; sendspin-js should filter 24-bit out of its negotiation since Web Audio is float32-only)

Context

Other audit-identified scenarios (drift injection, burst cadence, request-format renegotiation, external-source, multi-server arbitration, static-delay, volume curve) need adapter-side surface (a real playback pipeline or SDK hooks aiosendspin's reference adapter doesn't expose) before they can produce real signal. Those PRs were closed; they will be revisited as SDK surface lands.

Test plan

  • python -m compileall src scripts
  • python -m conformance.cli run --results-dir results --from aiosendspin --to aiosendspin --timeout-seconds 25 — the new server-initiated-pcm-24bit row passes; pre-existing scenarios still pass

Closes #60.

Adds a `server-initiated-pcm-24bit` scenario that emits the 24-bit
packed wire format (3-byte packed, little-endian, two's complement)
and reuses the existing `audio-pcm` verification mode. The aiosendspin
server feeds 32-bit source PCM into the SDK with AudioFormat(bit_depth=32)
because the SDK ingests PyAV-compatible samples; the negotiated wire
format from the client (24-bit) drives the output conversion to s24
via the SDK's existing s32→s24 path. Feeding raw 3-byte/sample input
to prepare_audio would fail inside PyAV with "got N bytes; need 4N/3
bytes" because there is no packed-s24 sample format in PyAV.

The 16→32-bit shift used here preserves the float-domain hash, so the
existing audio-pcm verification matches end-to-end. The client adapter
advertises bit_depth=24 at the fixture's native rate/channels so the
SDK does not resample during the round trip — only the bit depth
changes. Other client adapters that do not yet hardcode the new
scenario_id will fail their cases until they grow the matching
SupportedAudioFormat advertisement, surfacing per-SDK 24-bit decode
gaps (notably sendspin-go has no 24-bit code path and sendspin-js
should filter 24-bit out of its negotiation since Web Audio is
float32-only).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant