Sendspin conformance
Compatibility test results for Sendspin servers and clients. Select a result to view logs and test details.
Total cases
186
Passed
101
Unsupported
17
Failed
68
Test
Client initiates connection and client wants PCM
Start the server first, then the client. The client discovers or looks up the server, initiates the WebSocket connection, advertises PCM as its only supported audio format, streams audio derived from almost_silent.flac, and compares canonical PCM hashes.
Test
Server initiates connection and client wants PCM
Start the server first, then the client. The client advertises a listener and PCM as its only supported audio format, the server connects in, streams audio derived from almost_silent.flac, disconnects, and the matrix compares canonical PCM hashes.
Test
Server initiates a protocol baseline session
Start the server first, then the client. The client advertises a listener and PCM player support. The server connects, and both adapters record the handshake, role activation, initial state, stream negotiation, and timestamped player chunks for checks against the pinned spec revision. This test does not check audio decoding or playback.
Test
Server initiates connection and client wants Metadata
Start the server first, then the client. The client advertises a listener, the server connects in, sends a metadata state update, disconnects, and the matrix compares a normalized metadata snapshot and checks that the first state carrying a metadata object bore a past or present timestamp.
Test
Server initiates connection and client wants Artwork
Start the server first, then the client. The client advertises a listener, the server connects in, streams album artwork, disconnects, and the matrix compares the received bytes against the server's encoded artwork.
Test
Server initiates connection and client wants Controller
Start the server first, then the client. The client advertises a listener, the server connects in, observes controller state, receives a control command, disconnects, and the matrix verifies the recorded command.
Test
Server initiates connection and client wants FLAC
Start the server first, then the client. The server loads the PCM audio derived from almost_silent.flac, the client advertises a listener and FLAC as its only supported audio format, the server connects in, uses the SDK to encode the PCM into FLAC, streams it to the client, and the matrix compares the transported FLAC header and chunk bytes as received by the client. Where the client reports the audio it decoded and the stream kept the source's sample rate and channel count, the matrix also compares its canonical PCM hash against the source clip, so a stream that arrived intact but incomplete fails.
Test
Server initiates connection and client prefers OPUS
Start the server first, then the client. The server loads the PCM audio derived from almost_silent.flac, the client advertises a listener and lists OPUS first in its supported audio formats, followed by the PCM or FLAC entry every player must list. The server connects in and, being able to produce OPUS, is expected to honour that priority: it uses the SDK to encode the PCM into OPUS and streams it to the client. The matrix verifies the declared list, that the negotiated format is OPUS, and that the transported OPUS chunk bytes match as received by the client. OPUS is lossy, so decoded audio is not compared against the source.
Test
Server initiates connection and client wants 24-bit PCM
Start the server first, then the client. The server emits PCM in the 24-bit packed wire format (3-byte packed, little-endian, two's complement). The client advertises a listener and 24-bit PCM as its only supported audio format. The matrix compares canonical PCM hashes after the client unpacks the 24-bit stream. A client SDK with no 24-bit decode path misreads the bytes and produces a hash mismatch. The matrix also verifies that the negotiated stream was 24-bit, because a 16-bit stream of the same clip yields the same canonical hash without exercising the 24-bit path.
Test
Client changes its preferred PCM bit depth via client/state
Start the server first, then the client. The client connects, advertises two PCM formats (24-bit then 16-bit), and the server starts streaming the higher-priority 24-bit format. The client then sends a client/state whose player format prefers the 16-bit entry. The matrix verifies the server received that preference in client/state and the client observed a new stream/start in the 16-bit format.
Test
Client changes its preferred format from PCM to FLAC via client/state
Start the server first, then the client. The client connects, advertises PCM then FLAC, and the server starts streaming the higher-priority PCM format. The client then sends a client/state whose player format prefers the FLAC entry. The matrix verifies the server received that preference in client/state and the client observed a new stream/start in the FLAC format.
Test
Client initiates connection and client wants Metadata
Start the server first, then the client. The client discovers or looks up the server and initiates the WebSocket connection, the server sends a metadata state update, disconnects, and the matrix compares a normalized metadata snapshot and checks that the first state carrying a metadata object bore a past or present timestamp.
Test
Client initiates connection and client wants Artwork
Start the server first, then the client. The client discovers or looks up the server and initiates the WebSocket connection, the server streams album artwork, disconnects, and the matrix compares the received bytes against the server's encoded artwork.
Test
Client initiates connection and client wants Controller
Start the server first, then the client. The client discovers or looks up the server and initiates the WebSocket connection, the server observes controller state, receives a control command, disconnects, and the matrix verifies the recorded command.
Test
Server initiates connection over the legacy unencrypted transition mode
Start the server first, then the client. The server uses aiosendspin's allow_unencrypted mode to test clients that do not yet support the required Noise handshake. This mode is outside the spec and sends traffic without encryption. The test can be removed once all tracked implementations support the Noise handshake.
Test
Server initiates connection and frames PCM audio chunks
Start the server first, then the client. The client advertises a listener and PCM as its only supported audio format, the server connects in and streams audio derived from almost_silent.flac, and both adapters record each audio frame as it crossed the transport. The matrix verifies that every frame is message type 4 behind the 13-byte header (type, int64 timestamp, uint32 send_ahead), that the client read the same 13 bytes off each one, and that no chunk lasted longer than 150 ms or, the final chunk aside, less than 15 ms. This test does not compare the audio, and does not judge send_ahead saturation, which no adapter can observe.
Repository versions
Commits tested in this run, with changes since the latest tagged release.
Commit
Release delta
Commit
Release delta
Commit
Release delta
Commit
Release delta
Commit
Release delta
Commit
Release delta
Commit
Release delta
Commit
Release delta