Echo or barge-in? Diagnose a voice agent hearing itself

TL;DR: Diagnose a voice agent hearing itself by recording a consented output reference and the corresponding microphone or inbound media, then comparing silent-caller and genuine-interruption conditions. Repair the return path or echo-control configuration before changing turn thresholds, and verify that the repair preserves quiet callers and simultaneous speech.

---

Your agent begins a greeting, stops halfway through, and responds to words nobody in the room said. The transcript resembles the greeting because a copy of the output returned through the input path.

That is a plausible explanation, not a diagnosis. A recording loop, an incorrectly selected channel, another person repeating the phrase, or genuine caller speech can produce similar application events.

Start with the audio boundary. The interruption safety guide explains what to invalidate after a real interruption; this guide establishes whether the event represents a caller trying to speak.

The deliverable is a repeatable loopback experiment, a small offline signal check, and an acceptance record that keeps false interruption improvements separate from missed speech. These are generic engineering methods for evaluating a voice application, including an integration with 60db Agent, without making claims about a product's private implementation.

As of November 2026, the public WebRTC audio requirements recommend endpoint echo control. That recommendation does not certify a particular microphone, route, or application graph, so the test must cover the physical route your users have.

Table of contents

1. Locate the returning sound
2. Define evidence before tuning
3. Run a controlled loopback experiment
4. Check correlation without claiming speech recognition
5. Repair the right boundary
6. Keep double talk and quiet speech
7. Read traces without mixing clocks
8. Make the repair a release gate
9. Frequently asked questions
10. Leave with a reproducible diagnosis

Locate the returning sound

Echo is output energy returning to an input that should represent the caller. It can cross an acoustic path, an electrical path, or a software routing boundary, and each path suggests a different intervention.

Acoustic echo occurs when a loudspeaker plays into a room and a microphone captures some of that sound. Moving the devices, changing the speaker volume, or switching to headphones changes the physical path even when every network component stays the same.

A software loop can return output without a loudspeaker. A virtual audio device, a mixed recording track, or an adapter that feeds both directions into recognition can make a headset test fail just like a speaker test.

Telephony adds more boundaries. A gateway, a bridged leg, or a remote speakerphone can contribute a returned signal, so inspect media direction rather than assuming that every inbound frame originated at the local caller's microphone.

The transport comparison is useful when mapping those boundaries. A WebSocket label describes delivery, while the content and direction of the audio remain part of the application contract.

Draw the actual path on paper before adding an echo filter. Include every gain change, resampler, mixer, player, capture device, and recognizer input that is visible to your team.

Mark where the output reference is taken. A reference collected before a mixer can differ from the signal sent to the speaker if another source, a gain change, or queued audio appears later in the path.

That mismatch matters during diagnosis. A correlation test can miss a returning copy when you compare against the wrong response or against audio that was generated but never played.

The figure separates the path under investigation from the reference used to inspect it. Its arrows describe a possible acoustic path, not a measured route inside any vendor product.

Capture failures have a different signature. If the microphone track is muted, the device changed, or the recording contains only silence, an absence of detected echo says little about the original incident.

Keep the SIP troubleshooting checklist nearby for telephony cases. Establish working, correctly directed media before assigning a conversational explanation to a detector event.

Do not start by raising the minimum duration for an interruption. Echo can contain complete words and sentences, which gives a duration gate plenty of evidence to accept the wrong source.

A useful first question is whether the failure occurs with the caller silent. A second question is whether replacing the loudspeaker with headphones changes it, and a third is whether the same return exists in the audio entering recognition.

Those questions reduce the search space. They also expose a common debugging mistake: treating a transcript as the raw observation when several processing stages already changed the signal before transcription.

Define evidence before tuning

Use separate labels for the physical condition, detector behavior, and application decision. "False barge-in" alone collapses those fields and makes it hard to tell which component changed after a repair.

For each trial, record whether the caller intentionally spoke, whether output was active, whether an input speech event occurred, and whether the controller paused or invalidated the response. Add a human annotation for the audible source when a consented recording permits review.

The VAD and turn-detection guide explains why a speech event cannot establish turn intent. A detector can correctly notice speech-like audio while the application incorrectly treats it as new caller input.

Build the confusion table around a declared unit. A trial can be a greeting playback, a scripted overlap, or an annotated interval, but mixing these denominators produces rates that cannot be compared.

Count failed capture trials separately. If an input file is empty, exclude it from an accuracy denominator only under a documented rule and report the exclusion count beside the results.

The criteria below use ✓ for evidence the method can provide and ✗ for a conclusion it cannot support by itself. They compare diagnostic scope, not vendor capabilities or measured quality.

Make "unknown" a first-class annotation. A distant television and a quiet caller can overlap, and forcing every interval into echo or human speech creates false confidence in the tuning data.

Do not assign words such as "heard" to a microphone energy statistic. The WebRTC statistics specification defines audio energy fields, but those fields describe signal properties rather than the identity or intent of a speaker.

Use energy as a capture sanity check. An interval with no useful input samples should fail the experiment's data-quality check before it can contribute evidence for echo suppression.

Keep a short incident note containing the symptom, software versions, route, output level setting, and reproduction steps. Store consented audio under the team's retention rules rather than putting recordings into a broadly accessible issue tracker.

The observability guide provides a place to connect these events to response ownership. Diagnostic logs can usually preserve identifiers, reasons, and timing without preserving conversational content.

Write the intended repaired behavior before touching configuration: a silent caller should not create a new turn from output leakage, and a real caller should still interrupt while the assistant speaks. A repair that satisfies only the first half changes a duplex application into a one-sided player.

Run a controlled loopback experiment

Start with a local, synthetic utterance that contains no personal information. Use a fixed recording or fixed synthesis output so repeated trials send the same material through the path.

Choose words that are easy to distinguish from your caller script. For example, the output can describe a fictional library shelf while the caller asks to repeat a fictional room name.

This is a synthetic fixture. Neither script should sound like a real payment, account lookup, or customer conversation, because people reviewing the files should never mistake the trial for production evidence.

Run a silent-caller condition with the normal speaker route. Record the output reference and processed input simultaneously, and preserve the unprocessed microphone signal only if the platform exposes it safely and the test consent covers it.

Repeat with a headset. Keep the recognizer, server, prompt, and output recording unchanged so the route is the main altered variable.

Then run genuine interruptions on both routes. Ask the participant to speak at different points in the utterance, including near playback onset, during a loud vowel, and after a quiet pause.

Do not claim the headset condition removes every return path. It weakens a typical acoustic path while leaving software routing and some electrical paths available, which is precisely why it is a useful comparison.

Use the same device placement and document any movement. A participant leaning toward the microphone changes the relative level of caller speech and returned output, even if the application configuration remains fixed.

Keep automatic gain control in the record. A quiet room before playback can produce a different input gain state from a room where the participant has just spoken, so vary trial order or reset the route under a documented procedure.

For browser capture, inspect supported constraints and resulting settings rather than assuming a request succeeded. The Media Capture and Streams specification defines the relevant constraints and settings interfaces.

// Run from a user gesture on HTTPS or localhost.
async function openDiagnosticMic() {
  const supported = navigator.mediaDevices.getSupportedConstraints();
  const audio = supported.echoCancellation
    ? { echoCancellation: true }
    : true;
  const stream = await navigator.mediaDevices.getUserMedia({ audio });
  const track = stream.getAudioTracks()[0];
  if (!track) throw new Error("No audio track returned");
  return {
    stream,
    settings: track.getSettings(),
    stop: () => stream.getTracks().forEach(t => t.stop()),
  };
}

The snippet requests capture and exposes actual settings; it does not record audio, create a player, or certify cancellation quality. Close every track after the trial and avoid logging persistent device identifiers into shared reports.

A minimal experiment record contains a fixture identifier, device and route description, configuration snapshot, processing boundary, valid-capture status, and the annotated outcome. Use anonymous local trial identifiers rather than phone numbers or customer account identifiers.

Treat a route change as a new condition. Bluetooth, a wired headset, a handset earpiece, and a loudspeaker can have different processing paths, so one passing device does not cover the others.

The companion mobile browser guide helps organize device-specific checks. Browser lifecycle and audio route behavior need physical device coverage when those routes matter to users.

Check correlation without claiming speech recognition

An offline lag scan can show whether the input resembles a delayed copy of the output reference. It is a diagnostic aid, and its assumptions should be written beside its result.

The following standard-library example creates a synthetic reference, delays and attenuates a copy, and finds the strongest positive-lag normalized correlation. Save it as echo_probe.py and run it with Python 3.

from math import sqrt
from random import Random


def similarity(a, b):
    if len(a) != len(b) or len(a) < 2:
        raise ValueError("Equal nontrivial windows required")
    am = sum(a) / len(a)
    bm = sum(b) / len(b)
    aa = [x - am for x in a]
    bb = [x - bm for x in b]
    denom = sqrt(sum(x*x for x in aa) * sum(x*x for x in bb))
    return None if denom == 0 else sum(x*y for x, y in zip(aa, bb)) / denom


def probe(reference, incoming, max_lag):
    if max_lag < 0 or max_lag + len(reference) > len(incoming):
        raise ValueError("Incoming signal must cover every tested lag")
    scored = []
    for lag in range(max_lag + 1):
        score = similarity(reference, incoming[lag:lag + len(reference)])
        if score is not None:
            scored.append((score, lag))
    return max(scored) if scored else None


if __name__ == "__main__":
    rng = Random(17)
    reference = [rng.uniform(-1, 1) for _ in range(600)]
    incoming = [0.0] * 37 + [0.2*x for x in reference] + [0.0] * 43
    result = probe(reference, incoming, 80)
    assert result is not None
    score, lag = result
    assert lag == 37 and score > 0.999999
    assert similarity([0, 0], [0, 0]) is None
    assert probe([0, 0], [0, 0, 0], 1) is None
    try:
        probe(reference, incoming, 1000)
        raise AssertionError("Expected bounds rejection")
    except ValueError:
        pass
    print("Synthetic lag and silence checks passed")

The values in this code define a synthetic self-check. The lag is measured in samples of the constructed arrays, and it is not a latency measurement from a call, speaker, or service.

For real recordings, decode both inputs to the same sample rate and channel meaning before comparing them. Preserve the original files and conversion settings because a mistaken stereo downmix or resampling step can change the diagnostic signal.

Do not copy the random fixture into a live speaker test at arbitrary volume. Real acoustic testing needs safe, comfortable levels and an approved stimulus, while this array fixture exists only to verify the mathematics and bounds handling.

A high score at one lag supports a returned-copy hypothesis for that window. It does not determine whether an echo canceller should suppress the whole interval, especially when caller speech occurs at the same time.

A low score leaves several explanations open. Compression, nonlinear speaker distortion, clock drift, clipping, changing delay, a weak reference, and genuine caller speech can all reduce the match.

Run the scan on short, documented windows with enough non-silent content. Searching many lags increases the chance of an incidental best match, so preserve the full search range and compare against unrelated reference material as a negative control.

For analysis that needs frequency-dependent echo behavior, use an established audio analysis tool and retain its settings. This compact probe deliberately avoids pretending to replace a production echo canceller or a speech-source classifier.

The regression testing guide explains how to turn a discovered failure into a stable fixture. Keep the diagnostic recording separate from the deterministic array test, since they answer different questions.

A useful report says, "The processed input contains a delayed signal resembling the selected output during a valid silent-caller window." It should avoid saying, "The model proved the caller was silent," because the signal comparison cannot establish that fact.

Conceptual: Signal similarity supports a returned-copy hypothesis within the checked window, without establishing speaker intent.

Repair the right boundary

If the headset comparison removes the failure and the speaker condition reproduces it, inspect capture and playback processing at the endpoint. Confirm the microphone belongs to the intended route and that the output uses the player path expected by the platform's voice processing.

If both routes fail with a nearly identical return, inspect software routing first. Check whether a mixed recording or outbound telephony track entered the recognition adapter and whether the adapter's inbound/outbound names match the provider's documented meanings.

For Twilio Media Streams, use the public stream direction and track documentation to establish what the application receives. Preserve the distinction between a track selected for observation and media intended to represent caller input.

Avoid stacking independent cancellers without a test. A second processor can change caller speech and delay while making an isolated echo-only recording look cleaner.

The repair belongs where the evidence points. A browser capture configuration change can address a browser route; it cannot repair a server adapter that fed an outbound channel into recognition.

Output levels deserve inspection too. A path that clips the loudspeaker or microphone can violate the assumptions of a simple returned-copy model, so compare at safe, documented levels instead of using the loudest setting as the only trial.

A delay-aware reference must follow actual playback. Generated audio discarded after an interruption should not remain in the reference timeline as though it reached the speaker.

The playback acknowledgment guide explains the evidence boundary. "Generated," "sent," and "scheduled" identify different events and can lead you to compare against different audio.

For a custom player, track queue clears and route resets as explicit events. After a clear, a late chunk must not be accepted into either playback or the corresponding output reference merely because synthesis completed successfully.

The audio backpressure guide covers that stale-output problem. Queue age can make a correct reference appear misaligned when the application assumes output is playing immediately after generation.

If the root cause is unresolved, introduce a reversible containment with a named limitation. An explicit push-to-talk mode can preserve user control while the route is repaired, but it changes the interaction and should be visible to the user.

Muting microphone capture throughout every response also changes the interaction. It prevents the application from observing a real interruption and should never be presented as proof that echo cancellation now works.

Keep a rollback plan. Store the previous configuration, the condition under which it failed, and the comparison that supports the new setting, so a later device regression can be investigated without reconstructing the entire incident.

Keep double talk and quiet speech

A useful echo repair must preserve caller speech during playback. A silent-room test alone rewards any implementation that closes the input path while output is active.

Double talk means the local caller and remote output are active together. The difficult case is a quiet caller speaking while the loudspeaker carries a louder assistant response, because a broad suppression rule can remove the very interruption the application needs.

Build caller scripts around distinct behaviors. Include a short stop command, a longer correction, a spelled fictional name, and a hesitant request that starts quietly before becoming louder.

The backchannel guide covers acknowledgments that should not always transfer the floor. Keep those fixtures separate from explicit stop commands so a change in one category cannot hide damage in another.

Also include a caller repeating an output word. If the assistant says a fictional room name and the caller repeats it as a question, word overlap is expected and should not automatically erase the caller's turn.

This is why transcript deduplication is a weak echo repair. It can suppress a real request to clarify exactly the phrase that was just spoken.

Test speech onset near output onset. Processing state can differ when a route first starts, and a greeting can expose behavior that later turns do not reproduce.

Include route switching during a controlled session if users can switch devices. The before-switch condition and after-switch condition need separate annotations, because a reference aligned to the old route can be invalid after the change.

Test with background speech only under clear consent and safe fixtures. A recording of a synthetic television-like sentence can distinguish non-caller speech from output echo without collecting household conversations.

Measure two independent outcomes: whether the false interruption occurred and whether the intended caller command remained usable. A clean echo recording with a damaged stop command fails the repair gate.

For speech content, annotate the important intent and fields. A transcript can contain most of a correction while missing its negation or revised value, which is why workflow enforcement must remain separate from signal cleanup.

Do not let the echo classifier authorize a business action. Its job is to contribute evidence about the input source; confirmation, policy, and external operation state still belong to their own gates.

Listen to the output as well as the input. A controller that pauses repeatedly on harmless residuals can make the assistant hard to follow even if recognition eventually ignores the echoed transcript.

The overlap policy guide distinguishes reversible attenuation from committed cancellation. That distinction lets you contain uncertainty without treating every detected sound as a completed turn.

Conceptual: A repair needs both reduced false interruptions and preserved caller speech during playback.

Read traces without mixing clocks

A device capture timestamp, an audio-context position, a server receipt timestamp, and a provider media timestamp may belong to different clocks. Subtracting arbitrary pairs can manufacture a delay that has no physical meaning.

Use local monotonic durations for intervals measured within a process. Across processes, record the clock domain and synchronization method, and report uncertainty rather than hiding it in a single number.

The RTP specification defines media timestamps in the media clock domain. A media timestamp is useful for sample ordering and spacing, but it is not automatically comparable with a server wall clock.

Keep the sample rate attached to sample counts. A lag measured in samples becomes a duration only when the rate and any conversion history are known.

Do not treat a round-trip network time as an acoustic echo delay. The returning path can contain local buffering, device processing, and room propagation that a network ping does not observe.

A minimal trace links output chunk identity, actual admission to the player, relevant route state, input interval identity, detector event, and controller action. The identifiers should let you reconstruct a failure without including raw transcript text in ordinary logs.

The voice latency benchmark provides interval naming that helps keep those boundaries visible. Echo debugging benefits from the same discipline as latency measurement because both fail when an upstream event is mislabeled as downstream playback.

Review incident timelines in causal order. A speech event that preceded output admission cannot be caused by that output through the current route, although a previous buffered response remains a possible source.

Check old generations. If a canceled response is still in a downstream queue, the returned sound can belong to a previous response while the current trace points only at the new one.

That case can resemble a detector hallucination when the reference is incomplete. Preserve response ownership through the player and reference logs so the old utterance can be found.

For browser graphs, the Web Audio specification describes scheduling in the audio context's time coordinates. Keep those coordinates distinct from JavaScript event receipt times, which can be delayed by work on the main thread.

Do not promise sample-accurate acoustic alignment from application callbacks alone. The device and operating system retain their own buffers, and the instrumentation must state which part of the path remains unobserved.

Separate route failures from model failures

A useful escalation packet lets the next owner reproduce the boundary they own. If the input already contains a returned copy before recognition, send the capture or media owner the synthetic stimulus, route description, and aligned window rather than a screenshot of the model response.

If input is clean but a transcript repeats old output, preserve the recognition session boundaries and adapter event order. A reused buffer, replayed event, or stale transcript revision is a different class of failure from acoustic feedback and needs a different reproduction.

If the transcript is correct but the controller stops on a harmless acknowledgment, move the investigation to turn policy. The partial transcript contract helps distinguish recognition evidence from a command that the application is allowed to act on.

For each handoff, state one falsifiable hypothesis. "The outbound track reaches recognition on this bridge" can be tested by inspecting that track with a silent synthetic caller; "the voice stack is unreliable" gives the receiving engineer no boundary to inspect.

Keep the reproduction small enough to run without production credentials. A fixed synthetic file, a documented local route, and a trace with anonymous response identifiers are easier to review than a full customer call whose permissions and retention history are unclear.

Do not edit the original incident files when preparing a reduced fixture. Store the transformation recipe and retain the source according to its approved policy, since clipping, normalizing, or resampling the only copy removes evidence about how the failure appeared.

A reduction can also expose test assumptions. If the failure disappears when the greeting is shortened, the relevant variable may be queueing, processing startup, or the omitted phonetic content, so vary one factor at a time rather than concluding that long replies cause echo.

Keep a negative-control library

Store unrelated output references beside the matching reference for the offline lag probe. A method that reports equally strong matches for unrelated material needs investigation before its score is used to rank candidate repairs.

Include a repeated-tone negative control only as an offline array fixture. A periodic signal can produce many plausible lags, which teaches the team why a single best-lag value can hide ambiguity and why the stimulus should contain enough changing structure.

Add a fixture with independent caller speech over the returned copy. The diagnostic should report uncertainty about mixed sources rather than turning a good match into a rule that deletes every sample in the interval.

Keep the test names descriptive: silent speaker, silent headset, quiet correction, output-word repetition, and route switch. These names identify behavior that reviewers can understand without knowing an internal experiment number.

When a candidate fails, retain the failure even if another configuration passes. The library should explain the operating envelope and the reason for the selected setting; deleting inconvenient fixtures makes later regressions look new and encourages the team to repeat an already rejected change.

Conceptual: Join input and output observations by identity; subtract timestamps only with a justified clock relationship.

Make the repair a release gate

Run the same fixture matrix before and after the change. Preserve valid trial counts, route descriptions, software versions, and the annotations that explain each failure.

A release gate should require successful capture, no self-created turn in the declared silent-caller fixtures, preserved intended interruptions, and bounded residual output after a genuine stop. The exact numeric limits belong to your product and device coverage, so choose them before examining the candidate's results.

Keep unknown outcomes visible. A disconnected device or missing recording should not become a pass merely because the test harness saw no detector event.

Add a replay test for the controller decision whenever a real incident exposes a race. The offline signal trial investigates the cause, while the controller replay verifies that the application handles the resulting event order safely.

The shutdown semantics guide supplies a terminal condition: once a call ends, late echo or speech events cannot reopen playback. Include that boundary even if the original incident occurred during an ordinary greeting.

Record the smallest supported claim. "Passed the listed speaker and headset conditions on the listed devices" is useful; "echo solved" is too broad to guide the next engineer.

Keep diagnostic audio access narrow and time bounded. Synthetic fixtures can be shared broadly, while consented human recordings need a retention owner and a documented deletion path.

When introducing a new voice or output style, repeat relevant conditions. Changing the spectral content or loudness of output can expose a previously untested path without any application code change.

The multilingual benchmark guide offers a way to partition speech coverage. Do not assume that a quiet stop command in one language covers every language, speaking style, or microphone condition.

Finally, define the operational response to recurrence. A route-specific fallback, a visible manual control, and an evidence collection procedure are more useful than repeatedly increasing a global threshold during an incident.

---

Frequently asked questions

Why does a voice agent answer its own greeting?

A copy of the greeting can return through a speaker-to-microphone path or a software media loop and then enter recognition. Compare the output reference with valid input from a silent-caller trial before deciding which path is responsible.

Does a speech-start event prove the caller interrupted?

A speech-start event proves only that the detector's configured conditions were met at its input. Echo, nearby speech, and deliberate caller speech can all produce that event, so the controller needs source and intent evidence appropriate to the task.

Should I raise the interruption duration threshold?

Change that threshold only after identifying the failure and measuring the missed-interruption trade-off. Returned output can last longer than a real stop command, so a duration increase can leave echo intact while making callers harder to hear.

Does echo cancellation enabled mean echo is removed?

An enabled setting describes configuration rather than a quality result. Verify the resulting capture settings and run the actual speaker, microphone, and route conditions that matter to your application.

Why does using a headset help diagnose echo?

A headset changes the acoustic relationship between output and microphone while leaving much of the software path unchanged. If the failure disappears, that supports an acoustic explanation; a remaining failure keeps routing and electrical paths under investigation.

Can a software loop happen without speakers?

Yes. A mixed track, virtual device, or direction mistake can route assistant output into recognition before any physical playback occurs. Inspect the stream's documented channel meaning and compare the actual input payload with the output reference.

Can I remove repeated words from transcripts?

Repeated words alone are unsafe evidence for suppression because a caller can repeat a phrase to question or correct it. Use signal and route evidence, then preserve the caller's revised intent through a separate conversation policy.

What is double talk in this test?

Double talk is simultaneous caller speech and assistant output. It tests whether the repair can reduce returned output while preserving the caller, especially when the caller is quieter than the loudspeaker.

Is correlation enough to classify echo?

Correlation supports a returned-copy hypothesis for a defined signal window. It cannot establish intent, handle every nonlinear path, or guarantee that a real caller was absent from the same interval.

What should a silent-window result mean?

A silent or invalid input window should produce an unknown diagnostic result rather than a strong correlation score. Verify capture health before interpreting an absence of returned sound as a successful repair.

Why keep the exact output reference?

Generated speech may be discarded, attenuated, resampled, or delayed before playback. A reference tied to actual player admission makes the comparison more meaningful than a reference containing every audio chunk synthesis produced.

Can network jitter look like echo?

Jitter changes delivery and buffering, which can alter the delay of a returning signal or complicate alignment. It does not identify the return path by itself, so retain transport timing and audio observations as separate evidence.

Should the microphone be muted while the agent speaks?

That is a half-duplex containment choice that prevents ordinary spoken interruption. If you use it temporarily, expose an explicit way for the user to take control and do not describe the change as a verified echo-cancellation repair.

Does a clean transcript prove clean audio?

No. Recognition can omit audible leakage or suppress words while the detector still triggers on the signal. Review detector events and consented audio alongside transcription when diagnosing false interruptions.

Which device routes belong in regression coverage?

Cover the routes your users depend on, such as the handset, speaker, wired headset, and Bluetooth device. Record the physical device and software version because a passing route on one device cannot certify another.

How should diagnostic recordings be stored?

Use consented recordings with narrow access, a retention owner, and deletion rules. Prefer synthetic content for shared fixtures and keep personal conversations, phone numbers, and customer identifiers out of public reports.

Can another echo filter make the problem worse?

A second processor can alter caller speech or introduce delay even when it reduces an echo-only sample. Compare the complete fixture matrix and retain the previous configuration so the change can be reversed with evidence.

Should a new TTS voice trigger retesting?

Retest the speaker conditions that depend on output characteristics. A different voice, level, or speaking style changes the signal entering the acoustic path even when capture and transport code stay the same.

What should happen after a false interruption?

Keep the caller input available and resume only if the old response remains valid under the conversation policy. The resumption guide explains why blindly replaying queued speech can create a second failure.

What is the minimum useful incident report?

Include the reproducible condition, device route, configuration, valid-capture status, output and input boundaries, observed controller action, and known omissions. Separate the suspected cause from the evidence that supports it so another engineer can repeat the test.

Leave with a reproducible diagnosis

A useful repair package contains a route diagram, a consented or synthetic fixture, an input/output comparison, and a before-and-after matrix that includes genuine caller speech. Each item answers a different question and keeps a clean-looking recording from becoming an unsupported product claim.

Start with a silent-caller speaker trial and a headset comparison. Once the returning path is visible, change the smallest responsible boundary and rerun double-talk and quiet-speech coverage before changing global turn policy.

For a 60db Agent evaluation, ask for the observable capture, playback, and interruption boundaries your integration can verify. Use those boundaries to build your own acceptance record, and keep the conclusion scoped to the devices and conditions you tested.