Tyto

Tyto analyzes incoming user audio on the CPU. It returns a Tyto Risk Score and six Tyto Dimensions to help rank problematic segments and investigate audio conditions associated with failures in speech-to-text (STT), voice activity detection (VAD), turn-taking and speech-to-speech (S2S) systems. The score requires no transcript or specific STT provider. Validate it against your model, languages and traffic before automating interventions; it is not a measured error rate or a guarantee of failure. Use real-time analysis during a stream or batch call analysis for recordings. Both run inference locally; SDK authorization and telemetry have separate network requirements.

​

The Tyto Risk Score

What it measures: An audio-derived risk indicator for downstream STT, VAD, turn-taking or speech-to-speech failures. Lower indicates less problematic audio. Values range from 0 to 1; do not interpret a score of 0.50 as a calibrated 50% failure probability. How to use:

• Flag problematic user audio and trigger in-call interventions for voice agent use cases.
• Rank calls or user interactions by descending score and review the top N.
• As an internal monitoring indicator: “Fraction of analyzed windows with Tyto Risk Score ≥ 0.50”. Account for window overlap before interpreting this as call duration.

How to interpret: These bands are provisional triage examples. Calibrate them against labeled outcomes before using them as alerts or automatic controls: Calibrate real-time thresholds against your data. For offline triage, prefer percentile ranking within your traffic (“review the worst 1%”) over absolute thresholds. Caveats:

• Tyto was developed using English speech. Evaluate other languages explicitly; do not assume identical thresholds or predictive performance.
• Tyto uses a fixed 5 s context in this SDK release. Short or truncated inputs are padded and may not represent a full conversational segment. Analyze them as part of a longer stream rather than as sub-second clips.

​

Tyto Dimensions

Tyto returns six audio measures alongside the risk score:

1. Noise: Ambient non-speech noise behind the speaker.
2. Speaker Reverb: Speaker distance and room reverberance.
3. Speaker Loudness: Main-speaker level, a neutral measure rather than a degradation score.
4. Interfering Speech: Competing speech from people or media devices.
5. Packet Loss: Audio dropouts or discontinuities.
6. Codec Degradation: Lossy compression artifacts.

Track dimensions independently of the risk score: high packet loss may indicate network overload even when an agent succeeds. Dimensions can rise together or diverge; quiet audio can still contain severe discontinuities. All return values in [0, 1]. Higher values mean more problematic audio, except for speaker_loudness.

​

Noise (noise)

What it measures: The loudness of ambient or environmental noise behind the speaker. Low values indicate clean audio; high values indicate loud noise. Range [0, 1]. Sounds like: Clean / clear / noiseless ↔ noisy / hissing / buzzy / roaring. Think of call-center babble, traffic, kitchen appliances, wind, air conditioning or engine noise. Likely root causes: Cars, kitchens, drive-throughs, call centers or street noise. Device-side sources include fans, electrical hum and aggressive mix gain. How to use it:

• Real-time: Evaluate whether sustained high noise should trigger a prompt, manual turn-taking or adjusted interruption handling. Test false alarms before automating the intervention.
• Offline: Group low-conversion calls by environment to investigate audio-related causes.

​

Speaker reverb (speaker_reverb)

What it measures: Speaker distance and room reverberance. Low scores indicate dry, near-field audio (close mic); high scores indicate reverberant, far-field audio. Higher values indicate more echoey, problematic audio. Range [0, 1]. Sounds like: Direct / close / dry ↔ distant / echoey / hollow / “tunnel sound” / speakerphone-across-the-room. Likely root causes: Speakerphone use, laptops/phones at arm’s length or further, hard-walled or acoustically reflective rooms (kitchens, bathrooms, warehouses), in-car hands-free systems mounted far from the speaker. How to use it:

• Real-time: Sustained high reverb may indicate a distant speaker or reflective room. Consider prompting the user to move closer to the microphone.
• Offline: Correlate with transcription and endpointing errors. Reverb can smear word boundaries and delay VAD end-of-speech decisions, affecting turn-taking.

​

Speaker loudness (speaker_loudness)

What it measures: Main-speaker level, not audio quality. Low values indicate quiet speech; high values indicate loud speech. Range [0, 1]. Sounds like: At the low end: quiet but audible speech. At the high end: strong, present, possibly overdriven audio. Likely root causes (of consistently low values): Quiet talkers, mic far from the speaker, attenuation in the chain, failed or missing automatic gain control, low-output microphones or poor handsets. How to use it:

• Investigate consistently low values. Very quiet speech may be missed by VAD, STT or poorly calibrated gain control.
• High values are usually fine. Don’t alert on them in isolation.

​

Interfering speech (interfering_speech)

What it measures: Loudness of competing speech from people or media devices behind the main speaker. Lower indicates less problematic audio. Range [0, 1]. Sounds like: One clear voice ↔ competing voices: a colleague at the next desk, family members in the same room or dialogue from a nearby TV or radio. Likely root causes: Side conversations in offices, call centers, homes or public places, or speech from a nearby TV, tablet, smartphone or radio. How to use it:

• Real-time: Investigate background voices triggering VAD, interruptions or incorrect transcripts. Evaluate adjusted interruption handling or confirmation before acting on unexpected input. Ask the user to reduce competing speech without assuming its source: “Could you move somewhere quieter or turn down anything playing nearby?”
• Offline: Check transcripts for competing speech before using them for analytics or fine-tuning. Investigate whether background voices explain unexpected user turns or agent responses.

​

Packet loss (packet_loss)

What it measures: Audio discontinuities in the stream from network packet loss, jitter, frame erasure or CPU overload in your voice agent stack. Lower indicates less problematic audio. Range [0, 1]. Sounds like: Steady / smooth / continuous ↔ shaky / choppy / uneven, syllables clipped out, robotic concealment artifacts, words arriving “frayed”. Likely root causes: Caller-side network (mobile dead zones, congested Wi-Fi), carrier/PSTN impairments, jitter-buffer underruns, overloaded CPU or upstream media servers. How to use it:

• Real-time: Confirm inputs with missing content, especially names, email addresses and numbers. Consider longer end-of-speech timeouts when transport gaps could be mistaken for the user finishing.
• Offline: Group spikes by geography, carrier, time of day or deployment to investigate network and capacity issues. A discontinuity alone does not identify the responsible component.

​

Codec degradation (codec_degradation)

What it measures: Compression artifacts introduced by the lossy codec carrying the audio, such as Opus at a low bitrate. Low values indicate transparent, full-bandwidth audio; high values indicate heavily compressed audio. Range [0, 1]. Sounds like: Full and natural ↔ thin, muffled, metallic or “underwater”, with blurred consonants and missing high frequencies. Likely root causes: Low bitrates or aggressive bandwidth adaptation in your WebRTC or SIP path, narrowband telephony legs and PSTN gateways, transcoding between providers or a constrained caller-side network forcing the encoder down. How to use it:

• Real-time: Like packet loss, this is a transport problem rather than an acoustic one, so asking the user to change their environment will not help. Sustained high values are a signal to confirm inputs where detail matters, such as names, (email) addresses and numbers.
• Offline: Group by carrier, region, provider or deployment to identify excessive compression and distinguish pipeline degradation from acoustic conditions.

​

Qualitative dimensions quick reference

​

Real-time vs offline usage

Choose live monitoring or offline triage: Tyto runs inference locally. Measure analysis cost at your intended interval and concurrent-call count before choosing whether to score every call or sample traffic. Authorization and usage reporting may still require network access; see deployment. Choose the SDK entry point for your input:

​

Technical reference

​

Input requirements

• Sample rate: 16 kHz natively. Core SDK 0.24.0 accepts host rates from 8,000 to 192,000 Hz and adapts internally. Configure the collector with the actual input rate; external resampling to 16 kHz is not universally required.
• Window length: Tyto operates on fixed 5.0 s windows of audio, returning one set of values per window.
• Score the user channel: Tyto is intended for the audio your voice AI model hears: the human-to-model or human-to-agent direction. Though Tyto is not a TTS-output quality monitor, it may be used in some applications. For example, Tyto’s packet_loss dimension may be used to flag “stutter” in TTS systems arising under CPU overload.

​

Smoothing for real-time use cases

Smooth per-window scores before triggering interventions, such as switching to manual turn-taking, so a single spike does not trigger repeated actions. Alternatively, require N consecutive problematic windows. An exponential moving average (EMA) is one smoothing option: $$\text{EMA}(s_t) = \alpha \cdot s_t + (1 - \alpha) \cdot \text{EMA}(s_{t−1})$$ Use $\alpha = 0.3$ as an illustrative starting point, then calibrate it with your analysis interval and acceptable intervention delay. It is not a measured optimum for all traffic.

​

Aggregating over streams, calls or static audio files

Summarize per-window scores with:

• Mean: Overall call quality; simplest default for dashboards.
• p95 / max: Worst moments; good for triage ranking.
• Fraction of windows ≥ 0.30 (noticeable degradation): “how much of this call was bad”; a way to expose localized degradation, since a 30-second noise burst in a 10-minute call barely moves the mean.
• Per-dimension argmax: Which degradation dimension was largest, excluding speaker_loudness. This is the label to group by (“show me non-converted calls caused by noise”).

​

Using Tyto to flag problematic calls or audio files

Use call-level summaries to triage traffic:

• Flag problematic calls using a call-level aggregate such as the mean or fraction of windows ≥ 0.30 as a risk_score threshold.
• Identify why using the per-dimension argmax: which degradation dimension was largest. Exclude speaker_loudness from this comparison because it is a neutral level indicator. Do not treat the largest dimension as a causal explanation of the risk score. This is the label to group by across calls.
• Surface patterns by grouping flagged calls by their largest degradation dimension to investigate recurring conditions, such as interfering speech.

Use the audio evaluation guide to validate thresholds against your actual speech-to-text and agent outcomes.