Echo
In plain words: Voice: speech in and out
The speech area (Voice, or Echo) that follows an utterance from visible push-to-talk capture to transcription, an ordinary agent step, optional speech synthesis and observed delivery.
- 1First profile: visible push-to-talk, record-and-send; no always-on mic, wake word or full duplex.
- 2Roles: Ear (STT), Voice (TTS), speech-capable model, Listener (capture) and ordinary model.
- 3First local engine: audio.cpp with Parakeet TDT (STT) and Supertonic 3 (TTS), pending a Slovak bake.
Partial Engineering probes exist; native Echo admission remains designed.
Words on this page, decoded click one for its card
Voice Echo
Everything about speaking and listening.
It's like: The phone line and the interpreter.
Click a dot to open that part's card.
Between breath and hearing, a voice can vanish.
A spoken answer can be generated yet never heard. EchoVoice follows an utterance from deliberately armed capture to transcription, an ordinary Agent step, optional synthesis, and observed delivery. Source, consent, language, interruption, and playback chronology remain attached throughout.
The first passage is visible push-to-talk and record-and-send. Audio admission is Partial; a separate local engineering probe exercises speech without native EchoVoice grants or BridgeChat admission. State owns delivery and Audio owns the accepted law.
The resonance path
The first profile, record-and-send, carries one utterance through these steps:
visible bounded capture → immutable audio artifact → eligible Ear or audio-capable Mind → attributed transcript or native observation → ordinary Agent step → optional Voice → delivery evidence
Capture must be visible, bounded, and consented. Large bytes remain outside GraphStep Map checkpoints and queues.
Three distinctions keep the path honest:
ArtifactRefcarries metadata and grants no access. The explicit local custody seam can retain supplied WAV bytes and feed EchoVoice's inspector after separate authorization and admission; it captures no recording and supplies no playback or speech path.- Reliquary's accepted design preserves source and derivation; the first local profile retains source bytes and attributed claims, without a derivative graph. A transcript is an attributed interpretation, not a replacement for its recording.
- Synthesized audio is a new artifact. Generation proves neither delivery nor playback; receipts must state what actually reached the listener.
Later half- and full-duplex profiles must preserve one monotonic speech timeline through barge-in, contested turn ownership, interruption, cancellation, and reconnect. A live socket cannot supply those semantics.
A request must first pass audio validation, authority checks, and any remote-egress policy. Failure at one of those gates is a refusal. Waiting is appropriate only after those checks pass: if an otherwise eligible managed provider is not warm, the requesting RunJob Record may enter ordinary GraphStep Map StasisPause while OrchestratorStage Manager drains and readies the affected AnimatorsModel Runtimes. That wait does not let EchoVoice silently select a remote service, infer permanent microphone authority, inflate priority, or revoke another grant or lease.
The organs of resonance
AnA EchoVoice deployment composes five roles independently. Audio is material, never a capability
family. The labels stt (speech-to-text), tts (text-to-speech), and chat below belong to
current v1 compatibility; the Designed general-service interfaces define their own request and
return contracts.
| Role | Place in EchoVoice |
|---|---|
| Ear | echo.transcribe@1 AnimatorModel Runtime; current v1 projects stt |
| Voice (speech) | echo.synthesize@1 AnimatorModel Runtime; current v1 projects tts |
| Speech-capable Mind | Audio-input or audio-output model.chat@1 provider used under an admitted spoken-utterance contract; current v1 projects chat |
| Listener | Capture, push-to-talk, codecs, and optional voice activity |
| Mind | Ordinary reasoning provider; there is no separate voice intelligence |
EchoVoice's boundary is speech: utterance capture, STT, spoken-output synthesis, delivery, and playback chronology. It does not own music, sung performance, ambience, sound effects, picture/world sound, or generic audio understanding or generation. A model or engine that natively emits audio, video, or both gains no broader EchoVoice authority; every non-speech facet remains with its application and technical effect owner.
Applications may use speech without owning Echo
An application can use a speaking voice while continuing to own the work that voice serves. Riffmaw owns sung and otherwise musical performance; Language Edition owns casting, linguistic adaptation, timing, captions, and acceptance for one timed-language edition; Avatar may reference an exact eligible acoustic voice inside a presentation profile; and Broadcast owns canonical source words, editorial relation, and publication. EchoVoice supplies the speech contracts and lifecycle facts each work needs. The application references exact EchoVoice attempts and artifacts, so its account can follow capture, synthesis, delivery, and playback without maintaining a second version of that chronology.
The Companion device boundary
A future Companion client may own device capture and playback controls as EchoVoice's physical speech endpoint. A private Tether supplies reachability, not caller authority: Ward still authenticates and authorizes, while capture and consent remain visible. A remote Portal additionally requires eligible classification, egress policy, consent where required, and bounded cost. These are laws of the accepted design, not claims of delivered behavior.
First engine profile
The first planned native local profile starts with one inference engine:
| Concern | Initial choice | Boundary |
|---|---|---|
| Engine | audio.cpp | One pinned local runtime; support is family-specific, never arbitrary GGUF execution. |
| Ear candidate | Parakeet TDT 0.6B v3 | Multilingual STT candidate whose Slovak path must pass the bake. |
| Voice candidate | Supertonic 3 | Multilingual TTS candidate whose Slovak voices and OpenRAIL-M terms must pass the bake. |
| Connector | OpenAI audio batch dialect | Bounded transcription and speech routes only; runtime-native extras are not inferred. |
| Activation | Visible push-to-talk | No always-on capture and no wake-word dependency. |
| Interaction | Record and send | No claim of full-duplex speech or barge-in. |
Native admission remains Designed. Separate explicit engineering profiles exercise audio.cpp transcription and synthesis, or independently pinned whisper.cpp transcription with audio.cpp synthesis. Local qualification owns those profiles; State owns their measured evidence. They should prove speech-audio-to-text and text-to-speech-audio before exposing audio.cpp speech-voice conversion, cloning, alignment, VAD, diarization, codecs, or pipelines. Those functions become separately declared tool surfaces only after their model, inputs, outputs, custody, authority, and cancellation behavior are baked; the presence of a family in an upstream catalogue grants no LychD capability.
One connector may serve several compatible model profiles, but every profile keeps its own model identity, language facts, license, backend, resource measurements, and readiness. A language can be declared from upstream metadata without being verified by LychD. Routing uses an explicit request first, then ordered Principal or Persona preferences, then admitted detection; missing output-language support refuses rather than silently translating.
The first bake
Local speech qualification bounds the initial engineering probe separately from native AnimatorModel Runtime and BridgeChat admission.
The smallest honest evaluation fixes one runtime revision and model digest, then records:
- cold start, readiness, clean shutdown, cancellation, CPU/GPU placement, RAM/VRAM peak, and isolation from a resident Mind;
- transcription accuracy, endpoint truncation, names, numbers, mixed-language speech, confidence, and provenance for each language claimed as verified;
- synthesis latency, first audio, intelligibility, pronunciation, numbers, dates, currency, addresses, text normalization, and playback completion for each output locale and voice;
- exact OpenAI-compatible fields and errors rather than compatibility by endpoint name; and
- license and consent receipts before any voice-reference or cloning experiment.
Slovak is the first operator-selected reference bake, not a Core hardcode. Other users may order different input and output preferences, but every routed language owes the same evidence.
Watched alternatives
Speech provider study records the current Slovak, Czech and English candidates, immutable local packages and hosted-dialect differences.
The first profile does not implement these paths:
| Candidate | Why it remains watched | Promotion condition |
|---|---|---|
| NeMo-Speech.cpp | Narrower NVIDIA speech runtime with promising realtime, endpointing, word-timing, and Riva surfaces. | Stable pinned release and dialect, lifecycle and cancellation receipts, and a multilingual realtime bake that materially beats the audio.cpp path. |
| Piper | Small CPU TTS fallback with separately licensed voices. | A measured low-resource or recovery need that Supertonic through audio.cpp cannot satisfy, plus runtime and voice-license admission. |
| openWakeWord | Host-side wake-word candidate, not a speech server. | An authorized phrase/model with acceptable license, reproducible training or acquisition, and measured false-accept and false-reject rates in the target language and environment. |
NeMo-Speech.cpp may later reuse the batch connector through an explicit dialect, while its live WebSocket still needs a Resonance Session adapter. Piper and openWakeWord remain candidates rather than speculative runtime dependencies. No watched candidate is an automatic fallback, and no failed local attempt silently changes engine, language, or egress.