Read LL-TTS Status, Jitter, Underruns, and Source-DSP Timing

Interpret Signal's live TTS states and performance indicators without confusing them with end-to-end latency.

Written By 4ALL.LIVE

Last updated 1 day ago

Interpret Signal's TTS status and performance indicators so you can distinguish an unavailable publisher, a recovering receive path, and local playout pressure.

Best for: operators monitoring a live LL-TTS node or collecting precise evidence for troubleshooting.

Read the TTS states

  • Idle: the node is not actively receiving a translated stream.
  • Connecting: Signal is establishing or restoring the receive session.
  • Streaming: the node is receiving server-generated audio for the selected event and language.
  • Error: the node encountered a failure; use the displayed detail to determine whether it can retry or needs an external prerequisite restored.

A node may also report that it is waiting for translated audio or waiting for the event publisher. Waiting for the publisher points upstream to the designated Live Setup producer browser and its recording, lease, enablement, credentials, entitlement, wallet, cap, and network conditions.

Retries and backoff

Retryable TTS failures can move through reconnect attempts with backoff. Keep the graph stable, monitor whether the state returns to Streaming, and prepare the approved fallback. Repeatedly deleting or rebuilding a node does not repair an unavailable publisher or invalid entitlement.

Read jitter and underruns

  • Jitter depth is the amount of received audio currently buffered for playout.
  • Jitter target is the buffer level the receive path is trying to maintain.
  • Aggregate underruns count occasions when the receive or playout path did not have audio available when needed. Relate changes in the count to audible gaps and network or publisher events.

More buffering can improve resilience but can also increase delay. Treat the displayed values as operational evidence, not as a reason to change settings on air without an approved fallback.

Understand Source DSP timing

First-media-to-Source-DSP timing measures the interval from the first media received by Signal to the source DSP point. It excludes upstream capture, transcription, translation, generation, interface buffering, transmitter latency, and receiver latency.

Important: Source DSP timing is not end-to-end latency and is not a latency service-level agreement.

Verify the live node

  • The event and language are correct.
  • The state reaches and remains at Streaming during translated speech.
  • Jitter depth stays usable relative to its target.
  • Aggregate underruns do not increase with audible gaps.
  • Source and output meters confirm local audio beyond the status label.

Troubleshoot

  • Idle unexpectedly: confirm the pipeline is started and the node is connected.
  • Connecting repeatedly: inspect network access, authorization, event availability, and retry detail.
  • Waiting for publisher: restore the designated producer's active recording, lease, LL-TTS enablement, and network path.
  • Streaming with silence: check whether translated speech is being demanded, then trace the node meter, graph, processing, and output.
  • Rising underruns: protect the fallback and investigate publisher, network, workstation load, and buffering as separate stages.

Operational boundary

These indicators describe the Signal receive and local DSP path. They do not guarantee wording, accuracy, terminology, synchronization, downstream RF performance, or listener experience.