Direct answer
Test the audio format at the point where it is actually produced and again at the point where it is handed to inference. An AudioRecord constructor request, a WAV header, and the model’s expected input are three different facts. Android’s AudioRecord reference exposes configured properties such as sample rate and recording state; applications should also record the exact channel configuration and PCM encoding used for the active capture path. The captured bytes need to match the metadata written into a WAV wrapper. If conversion or resampling occurs, record its input and output properties and the implementation revision. A successful file write does not prove that the downstream recognizer interpreted the samples as intended. The current Cove shared InferenceEngine wraps PCM audio as WAV and submits it with a transcription instruction through LiteRT-LM; the current code configures audio execution on a CPU backend. This is a repository fact about that implementation, not a general statement about all Android audio routes or all model runtimes. The Cove Voice pipeline segments PCM, processes segments sequentially, merges non-empty results, and preserves a visible placeholder for a failed segment. A test should therefore follow audio through capture, conversion, segmentation, WAV packaging, inference, and merge, recording boundaries rather than treating the final transcript as a single opaque result. Build a fixture matrix around actual recorded properties: requested and observed sample rate; mono or multichannel layout; PCM representation; frame count; byte length; buffer or segment boundaries; and any resampler or WAV metadata. Include short input, silence, known-tone or synthetic waveform controls, ordinary speech, and an interrupted or malformed buffer case. Avoid recording real private speech for a public test corpus. If a platform reports only configured values and not a verified physical signal property, say which value was observed and do not overstate it as a measurement of hardware output quality. Use invariants that can be checked without declaring transcription quality: the frame count and bytes agree with the selected PCM representation; WAV header fields match the packaged payload; segment boundaries do not split data contrary to the pipeline contract; and the same synthetic fixture reaches the inference boundary with recorded provenance. Then add task-specific checks for expected transcript properties, while preserving a separate “model result” field. A mismatch at the audio boundary should not be fixed by changing prompt text or claiming unsupported language behavior. Conversely, a transcript error with a valid format does not prove the sample rate was wrong. The project has no complete real-device benchmark dataset, so these steps support reproducible troubleshooting, not a universal rate, compatibility list, accuracy percentage, or speed claim. Report the exact device, OS, app build, capture API/configuration, artifact, runtime, backend, input fixture, transformations, failures, and raw measurements. The most helpful finding is a trace that shows the first boundary where expected properties change and what recovery occurred.
A transcription works in one recorder fixture but fails after format conversion
A team uses Android recording and sends PCM through an application pipeline that adds WAV framing before local inference. A failure report says only “recognition is empty”; the sample format, header, segment size, and conversion history were not recorded.
Decision
Instrument each data boundary with format metadata and replay synthetic controls before changing the model prompt or asserting device compatibility.
Expected outcome
The team can locate whether mismatch occurs at capture, PCM conversion, segmenting, WAV packaging, or model inference and reproduce the result on the named setup.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Recorder configuration and device identity
- Known audio and transcript fixtures
- Format, clipping, failure, and recovery records
A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.
Implementation workflow
- Freeze the capture and model path. Record app build, Android version, recorder API and constructor settings, requested and reported sample rate, channels, encoding, runtime, artifact, backend, and transcription instruction. Identify exactly which values come from configuration versus a runtime query.
- Validate raw PCM accounting. For a controlled fixture, record bytes read, frame count, channel count, encoding, and segment boundaries. Check that byte arithmetic follows the format used; treat error codes, zero-length reads, and short buffers as separate outcomes instead of valid silence.
- Check resampling and WAV metadata. If the app transforms audio, capture before-and-after properties and the resampler revision. Verify WAV fields against the actual payload and ensure header declarations match sample rate, channels, bit depth, and data length. Do not infer these from a filename.
- Trace the exact handoff to inference. Capture a non-sensitive synthetic test artifact or checksum and the metadata at the call boundary. Follow segmentation and merge semantics; retain a separate failure state when one segment is missing or rejected rather than fabricating a contiguous transcript.
- Replay controls and scope the report. Run silence, synthetic waveform, short known speech, malformed buffer, and cancellation controls on the declared setup. Repeat after each single change. Report raw properties and the first changed boundary; keep unsupported accuracy or device-family claims out of the conclusion.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The report distinguishes requested capture format, queried/configured AudioRecord properties, WAV metadata, and downstream model input.
- PCM byte/frame/segment accounting is validated with controlled fixtures, and malformed or short reads have explicit outcomes.
- Every transformation has a recorded input/output format and version; format mismatch is not “fixed” by unrelated prompt edits.
- Conclusions name the tested configuration and do not generalize a format result to untested devices or transcription quality.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Requested format | Recorder builder/configuration values | Documents what the app asked for; not alone proof of resulting bytes or recognizer compatibility. |
| Observed capture and package | AudioRecord properties plus PCM/WAV boundary checks | Shows what the active path reports and whether metadata matches payload construction. |
| Inference acceptance | Exact artifact/runtime task with separate transcript assertions | Tests downstream behavior; a valid format and a correct transcript are separate conclusions. |
Failure patterns to prevent
- Assuming requested format was granted
- Resampling without versioned provenance
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does AudioRecord.getSampleRate prove the microphone delivered perfect samples at that rate?
It reports a configured sample-rate property for the AudioRecord instance. Preserve that meaning in the report; validate the actual data path and transformations separately, and do not turn it into a claim about signal quality.
If WAV playback works, is the model input format correct?
Not necessarily. Playback is a different consumer and may tolerate metadata or format differences. Verify the WAV header, payload accounting, segment boundaries, and the exact runtime handoff independently.
Can one device test establish a supported sample-rate list?
No. It records behavior for the named device, OS, app, capture configuration, artifact, and runtime. A broader support list requires raw, repeated evidence for each configuration it names.