直接回答
应在音频实际产生的位置，以及交给推理的位置分别验证格式。AudioRecord 构造参数、WAV 头和模型预期输入是三项不同事实。Android AudioRecord 参考 API 暴露采样率、录制状态等配置属性；应用还应记录活动采集路径实际使用的声道配置和 PCM 编码。实际字节必须与 WAV 封装中声明的元数据匹配。如果发生转换或重采样，要保存其输入、输出属性和实现版本。文件成功写出，并不能证明下游识别器按预期解释了样本。 当前 Cove 共享 InferenceEngine 会将 PCM 音频包装为 WAV，与转写指令一起交给 LiteRT-LM；当前代码将音频执行配置为 CPU 后端。这是关于该代码实现的项目事实，不是对所有 Android 音频路由或运行时的通用说法。Cove Voice 管线会将 PCM 分段、顺序处理，合并非空结果，并为失败片段保留可见占位。因此，测试应跟踪采集、转换、分段、WAV 封装、推理和结果合并全过程，记录每条数据边界，而不是把最后的文本视为一个不透明结果。 测试矩阵应围绕实际数据属性：请求和报告的采样率、单声道或多声道布局、PCM 表示、帧数、字节长度、缓冲区或分段边界，以及任何重采样器或 WAV 元数据。加入短音频、静音、已知音调或合成波形控制、普通语音，以及中断或格式错误缓冲区用例。公开测试语料不要使用真实的私密语音。如果平台仅报告配置值而没有验证物理信号属性，应说明观察到的究竟是什么，不能把它夸大为硬件输出质量测量。 应使用不必先判断转写质量的格式不变量：帧数和字节数符合所选 PCM 表示；WAV 头字段与载荷一致；分段边界符合管线契约，不会在数据格式不允许的位置切开；并且同一合成夹具带着来源信息到达推理入口。然后再为任务加入转写属性检查，同时单独保存“模型结果”字段。音频边界不匹配，不能靠改提示词或声称设备兼容来修；反过来，格式有效但转写出错，也不能证明采样率错误。 项目尚无完整真实设备基准数据，所以这些步骤用于可复现排错，不支持通用采样率清单、兼容列表、准确率百分比或速度结论。报告需要列明实际设备、系统、应用构建、采集 API/配置、模型制品、运行时、后端、输入夹具、转换步骤、失败与原始测量。最有帮助的结论，是一条能指出预期属性首次发生变化的位置以及随后如何恢复的轨迹。 为避免报告互相矛盾，把单位与格式也纳入数据结构。采样率用赫兹记录，帧数与采样数不能混写；多声道数据要说明一个帧包含哪些通道；位深与编码类别应对应真实数组类型或缓冲区格式。WAV 头生成器若从默认值读取属性，也要把默认来源记录下来。不要把“文件扩展名是 wav”当成包含了所有元数据的证据。格式不变量一旦写成测试，就能在更新录音库或重新组织分段时及早发现行为变化。 最后，音频夹具及故障报告应遵循最少数据原则。可用合成波形检验采样与封装边界；如果确需语音样例，应先取得许可并移除不必要的身份内容。对外报告可以保留格式、阶段、错误码和制品版本，但不需要附完整录音或原始转写。这样既能让问题在代码入口处重现，也避免把技术诊断变成持久保存用户语音的理由。
一种录音夹具成功，格式转换后转写变为空
团队使用 Android 录音，将 PCM 经过应用管线加上 WAV 封装后送入本地推理。故障记录只写“识别结果为空”，没有保存样本格式、头部、分段大小或转换历史。
决策
为每个数据边界加入格式元数据，用合成控制样例回放后再改提示词或声称设备不兼容。
预期结果
团队能定位采集、PCM 转换、分段、WAV 封装或模型入口的首次差异，并在标明的配置上复现。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- ANDROID-AUDIO-01：Android 媒体文档定义平台采集 API；应用还需负责录音权限、生命周期和格式边界。
- COVE-ASR-01：当前共享 InferenceEngine 将 PCM 包装为 WAV，再通过 LiteRT-LM 与转写指令提交；当前代码将音频执行配置为 CPU 后端。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 冻结采集与模型路径. 记录应用构建、Android 版本、录音 API 与构造参数、请求及查询到的采样率、声道、编码、运行时、制品、后端和转写指令。明确每个值来自配置还是运行时查询。
- 校验原始 PCM 计数. 使用受控夹具记录读取字节数、帧数、声道数、编码和分段边界。按格式检查字节换算；错误码、零长度读取和短缓冲区要分别处理，不能都当作有效静音。
- 检查重采样与 WAV 元数据. 应用有转换时，记录转换前后属性及重采样实现版本。校验 WAV 字段与真实载荷一致，包括采样率、声道、位深和数据长度；不要从文件名猜测这些信息。
- 跟踪推理调用处的数据. 记录不含隐私的合成测试制品或校验信息，并在调用边界保存元数据。检查分段和合并语义；某段缺失或被拒绝时保留独立失败状态，不伪造连续转写文本。
- 回放控制并限制结论范围. 在声明的配置中运行静音、合成波形、短已知语音、错误缓冲区和取消控制。每次只改一个变量后重复。报告原始属性与首个变化边界，不附加未经验证的准确率或机型家族结论。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 报告区分请求的采集格式、AudioRecord 查询/配置属性、WAV 元数据和下游模型输入。
- 使用受控夹具验证 PCM 字节/帧/分段计数；错误或短读取有明确处理结果。
- 每次转换都记录输入、输出格式和版本；不会用无关提示词改动掩盖格式错配。
- 结论限定于被测配置，不把格式结果外推成未测设备兼容性或转写质量。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 请求格式 | 录音器构造或配置值 | 说明应用请求了什么；单凭它不能证明字节内容或识别器兼容。 |
| 采集与封装观察 | AudioRecord 属性加 PCM/WAV 边界检查 | 展示活动路径报告了什么，以及元数据是否匹配载荷。 |
| 推理验收 | 准确制品/运行时任务及独立转写断言 | 测试下游行为；格式有效与文本正确是两种不同结论。 |
需要避免的失败模式
- 把构造 AudioRecord 时请求的采样率当成已验证的最终数据属性。
- WAV 文件能播放就认定模型收到的数据格式正确。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
AudioRecord.getSampleRate 能证明麦克风完美按该采样率交付样本吗？
它报告 AudioRecord 实例的配置采样率属性。报告中应保持这一定义；实际数据路径与转换仍要另行核验，不应把该字段夸大为信号质量结论。
WAV 能播放是否说明模型输入格式正确？
不一定。播放器是另一种消费者，可能容忍元数据或格式差异。应分别核对 WAV 头、载荷计数、分段边界和运行时实际收到的输入。
一台设备的测试能建立支持的采样率列表吗？
不能。它只记录指定设备、系统、应用、采集配置、制品和运行时下的行为。更广泛的列表需要为列出的每个配置提供原始且可重复的证据。