Natural AI toy conversation depends on the entire audio path: microphone, speaker, enclosure, processing, network and speech services. A successful response on a development board does not prove that a plush-covered product can listen clearly while playing speech or moving its motors.
This guide defines tests to agree before approving an engineering sample. It does not report measured EmotiToy performance for an untested platform.
AEC, TTS and Interruption Are Different Functions
Acoustic echo cancellation (AEC) reduces the contribution of the device's own playback in the microphone signal. Noise suppression addresses other noise. Voice activity detection identifies speech activity. Text-to-speech (TTS) produces spoken output from text.
Espressif's Audio Front-end Framework documents these processing functions. Their availability and configuration depend on the selected integration. AEC alone does not establish usable full-duplex conversation.
Interruption, or barge-in, requires the complete system to recognize a new user turn, stop or cancel old output and handle the next response consistently. Device audio buffering, transport, service cancellation and conversation state can all affect the result.
Prepare a Repeatable Test Setup
Record the board and firmware revision, selected backend, voice settings, network, speaker volume and microphone position. State the speaking distance and background-noise conditions. Test the final enclosure, plush fabric and stuffing; repeat after meaningful mechanical changes.
Use a fixed script in each required language. Include greetings, short questions, follow-up questions, numbers, names and longer responses. Ask a fluent speaker to review output quality. Tuya's language documentation explains why both ASR and TTS support matter; a menu label alone is not an acceptance result.
Test Matrix
| Scenario | Procedure | Record |
|---|---|---|
| Quiet conversation | Ask the fixed script with motors off | Recognition errors, response relevance and timing |
| Playback echo | Let the toy speak without a user speaking | False wake-ups or self-triggered turns |
| Mid-sentence interruption | Speak at an agreed point during output | Detection, stop time and whether old speech resumes |
| Rapid consecutive turns | Ask a follow-up immediately | Lost speech, overlapping output or stale answers |
| Motion noise | Repeat with intended motor sequences | Recognition changes, vibration and mechanical noise |
| Network interruption | Disconnect and restore the network | Error indication, recovery and retained state |
Agree pass/fail thresholds for the intended product before testing. Do not substitute an arbitrary universal latency target for the project's measured requirements.
Check Streaming Speech Quality
Listen for missing first syllables, clipped endings, duplicated fragments and unexplained pauses. Test punctuation, abbreviations, numbers, local names and long answers. If punctuation is spoken aloud, capture the response text where available and the audio so the team can distinguish text generation, segmentation and speech rendering issues.
Repeat with the same prompt and record whether the failure is consistent. A single edited demonstration can hide buffering or recovery problems.
Test the Physical Product
Microphone placement, speaker leakage, fabric and stuffing alter the acoustic path. Motor vibration near the microphone may need mechanical isolation or behavior changes. Compare listening with motion paused and motion active. Check at the intended volume range and battery conditions.
Additional microphones or software changes should follow observed failure causes. They are engineering choices, not automatic guarantees of improved performance.
Report and Approve Results
Keep a test log containing the question, language, settings, recording, timestamps and expected behavior. Define separate acceptance for recognition, answer generation, speech output, interruption and recovery. Retest after changes to firmware, voice service, enclosure or motor behavior.
The Xiaozhi client and separate server project are useful upstream references for investigation. Release notes and software feature lists are not proof of finished-product test results.
For hardware and project scope, see ESP32-S3 module development, multilingual voice testing and motion integration. Contact EmotiToy with your test requirements and sample brief.
References reviewed October 24, 2026.
