Offline Translator Does Not Detect Voice: Diagnosis

Direct answer

When a voice translation screen says it detected no speech, diagnose the earliest stage with evidence instead of blaming the translation model. Verify user action and permission, whether the recorder started, whether audio frames arrived, whether the buffer format matches the consumer, whether the segmenter emitted data, and whether recognition returned text. Only after a source transcript exists should translation be investigated. `ANDROID-AUDIO-01` defines Android audio-capture APIs and responsibilities, while `COVE-ASR-02` describes the repository’s sequential PCM segmentation and non-empty result merge. These facts support a stage trace; they do not identify any “common error” or prove a given device’s microphone works. Start with state, not a fix list. Record app build, device/OS under test, permission state, recording state, selected audio source if exposed, input route, declared sample format, and lifecycle events. Ask the user to begin recording explicitly and show a visible recording state. If permission is denied or revoked, stop cleanly and explain how to retry. Do not request broad storage access to solve a microphone issue. Android’s `AudioRecord` API exposes initialization and recording states, read results, and error codes; use the exact API contract and observed result rather than copying unverified forum workarounds. Inspect capture before transcription. Confirm a recording session actually starts, its read operation returns data rather than an error or zero-length block, and buffers are consumed by the intended task. Treat `ERROR_DEAD_OBJECT` as an API-defined recording state that requires rebuilding the recorder according to platform guidance, not evidence of a translation defect. Check route changes and focus interruptions, but do not equate “microphone permission granted” with audio frames available. Avoid logging raw PCM or private utterances; synthetic tones or consented short fixtures can show whether the capture path is active. Then inspect segment boundaries. Record segment identifier, sample format, duration metadata, empty-segment state, and the decision to submit or skip it. Test silence, an utterance cut at the start, brief pauses, and a normal phrase. A voice-activity gate can suppress quiet speech, but do not change thresholds blindly or claim a fix without reproducing the behavior. If a task uses a foreground service for microphone capture, verify its declared service type and current permission/lifecycle state; don't claim that simply adding a service makes every background recording valid. Only after a non-empty source transcript is confirmed should you inspect translation. Compare the recognized text to the checked source, then evaluate target translation independently. If transcript text is missing, classify the failure in capture or recognition and keep the translation stage marked not reached. If recognition text exists but translation is blank, record a separate output/parser/runtime failure. Retain cancelled, empty, malformed, and failed runs; never describe an error as frequent or common without a fact card. Use a controlled recovery matrix: fresh install, permission allow/deny/revoke, wired or Bluetooth route change only when relevant, app background/foreground, process recreation, recorder initialization failure, empty reads, segmenter empty output, recognizer failure, and translator failure. For every condition define user-visible state, cleanup, and retry. Test the next recording after recovery to ensure stale recorder objects or collectors are not reused. The report should show which stage is verified and which remains unknown, plus exact logs with private content removed. Do not promise that changing sample rate, selecting a chipset, reinstalling, or adding permissions fixes all no-speech cases. Results depend on implementation and environment. The useful outcome is a reproducible trace from permission through capture and recognition to translation. It narrows diagnosis without inventing device compatibility or claiming that a generic error message has a universal remedy.

A user taps the microphone but sees no transcript

The app shows a generic no-voice message. The team has no raw diagnostic record and cannot yet tell whether permission, audio acquisition, segmentation, or recognition failed. Investigation should stop at the earliest unverified stage and avoid requesting private recordings by default.

Decision

Add a privacy-safe stage trace and reproduce with a short consented fixture, stopping the investigation at the first unverified boundary.

Expected outcome

Support can state whether audio was acquired and whether recognition ran without inventing a universal fix or logging the utterance.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Permission and route state
• Known audio and transcript fixture
• Stage trace and retry result

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Record permission and lifecycle state. Capture grant/denial, user start action, activity/service state, focus interruptions, and recorder initialization result. Avoid extra permissions unrelated to microphone capture.
2. Verify frames and format. Check AudioRecord state and read results using the documented API contract. Record format metadata and whether non-empty buffers reached the intended consumer.
3. Trace segmentation and silence decisions. Record segment IDs and empty/skip decisions for silence, clipped start, pauses, and a checked phrase. Do not adjust thresholds without a reproduced case.
4. Separate recognition from translation. Compare any transcript with the source fixture first. Mark translation as not reached when no transcript exists; handle blank parser/runtime output as a different stage.
5. Recover and re-record. Inject permission change, route change where relevant, process recreation, and recorder/recognizer failures. Confirm resources close and a subsequent recording starts fresh.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• A trace identifies the earliest confirmed stage and distinguishes permission, capture, segmentation, recognition, and translation outcomes.
• Empty or failed recordings are recoverable, resources and collectors are cleaned, and the retry does not reuse stale audio state.
• Diagnostics exclude private audio/text, and no “common error,” universal fix, or device-support claim is made without recorded evidence.

Decision table

Failure patterns to prevent

• Blaming translation before capture
• Requesting broad permissions

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove Voice transcription
• Android AudioRecord reference
• Android AudioRouting reference
• Android audio capture overview

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions