Skip to main content
Use playAudio to send audio from your WebSocket application to Vobiz for playback to the caller. The stream must use bidirectional="true".
Inbound and outbound formats are independent. start.mediaFormat describes audio Vobiz sends to your application. playAudio.media describes audio your application sends to Vobiz. The two directions can use different supported formats.
playAudio bypasses the conference mixer. Audio sent this way is injected into the call leg the stream rides, not into the conference mix. Three consequences:
  • deaf cannot silence it. Deafening a member suppresses what the mixer sends them, and playAudio never passed through the mixer - a deafened member still hears anything played onto their own leg.
  • A stream can only address its own leg, never the room. To reach other participants use the per-member Play or Speak routes.
  • mute on a leg does blind a stream attached to it, because the media bug taps that leg’s inbound audio - exactly what mute suppresses.
This also means deaf cannot be tested against an AI agent at all. Testing it needs two human participants: deafen one, have the other speak.

Event fields

Supported outbound playback formats

Your payload must genuinely match the declared contentType and sampleRate. Changing sampleRate in JSON does not resample the audio. A mismatched rate, stereo payload, file header, or incorrectly encoded payload can produce slow, fast, distorted, or silent playback.
For audio/x-l16, send signed 16-bit mono samples. For both formats:
  • Remove WAV, MP3, or other file-container headers before Base64 encoding.
  • Generate or resample the source audio at the declared rate.
  • Validate the payload in your application before sending it. A playback checkpoint confirms queue progress, not encoding correctness.

Send audio at 8, 16, or 24 kHz

The XML does not change when you change the outbound playback rate. Change both the real audio payload and media.sampleRate in the playAudio event.
For example, your application can receive inbound L16/8 kHz audio in media events and send an outbound L16/24 kHz TTS response with playAudio.
Do not set <Stream contentType="audio/x-l16;rate=24000"> to request 24 kHz playback. <Stream contentType> configures inbound Vobiz-to-application audio. Set 24000 on the outbound playAudio.media.sampleRate field.

Choose a chunk size

Send playback in approximately 20–60 ms chunks for responsive barge-in and predictable queueing. This is a recommendation, not a requirement. For L16, calculate the raw payload size with:
Smaller chunks let clearAudio discard queued speech sooner when the caller interrupts. Keep the chunk duration and payload format consistent within an utterance.

Send playback from Node.js

Pass raw mono audio to audioBuffer. If your TTS provider returns a WAV or another container, extract the raw samples before calling this function.

Track playback completion

After the final playAudio chunk for an utterance, send a checkpoint:
When playback reaches that checkpoint, Vobiz sends:
  • A WebSocket playedStream event with the checkpoint name.
  • An HTTP PlayedStream status callback when you configured statusCallbackUrl.
If the caller hangs up or clearAudio removes queued audio before the checkpoint, the completion event may not arrive. Use a timeout in your application instead of waiting indefinitely.
Sending L16/24 kHz audio to Vobiz does not guarantee 24 kHz audio at the handset. The carrier, SIP, or PSTN leg may use a lower-rate codec.

Next steps