Nova Sonic Bridge

audio in → Amazon Nova Sonic → audio out, over one WebSocket
idle

The call

Like an inbound call: the agent speaks first, then you reply. Talking over it triggers barge-in.
The deployed endpoint is public and needs the token. Local needs no token. If a connection just hangs, check the endpoint and token above.

Send audio

No file chosen.
Live mic streams continuously, like a real phone line.

Transcript

Nothing yet.

Counters

0
frames sent
0
frames recv
0
KB sent
0
KB recv
sample rate

WebSocket messages (the actual wire format)

Messages appear here as they go over the socket. Base64 is truncated for readability — the real length is shown after each one.
What am I looking at?

Every audio message in both directions is exactly this shape:

{"type": "audio", "data": "<base64 pcm16>"}
PCM16The raw audio itself — 16 000 sample values per second, 2 bytes each, signed, −32768…+32767. Not a codec or container; a speaker plays it directly.
base64Only present because JSON is text and raw bytes would break the string. Costs ~33% in size and is perfectly reversible.
one frame32 ms of audio = 512 samples = 1024 bytes raw → 1368 base64 chars → ~1397 bytes of JSON (1.36×).
passthroughThe bridge copies this base64 string straight into Nova Sonic's audioInput.content field and copies its reply straight back out. No transcoding.
turn takingThere is no "end of turn" message. Nova Sonic's own voice-activity detection decides when you stopped talking, so silence must keep flowing — which is why the file mode appends 1.5 s of silence after your clip.
resamplingThis page converts whatever you upload to 16 kHz mono before sending. In production that job belongs at the LiveKit edge, not in the bridge.