Google-speech-api抛出EOF错误无法完成音频转录的解决方案求助

1. 校验音频参数与API配置的匹配性 #

• audiofork默认推送的是16bit小端序、16kHz采样率、单声道的PCM裸流，必须在StreamingRecognizeRequest的配置中严格对应：编码指定为LINEAR16，采样率填16000，声道数填1，任意参数不匹配都会导致谷歌服务校验失败直接断开连接返回EOF。
• 若你在Asterisk中配置audiofork输出的是ulaw/alaw等压缩编码，必须先转码为LINEAR16格式再发送给API，不要直接透传压缩编码数据。

2. 修正流式请求的发送顺序 #

• 谷歌流式识别要求第一帧必须发送StreamingRecognitionConfig配置帧，后续才能发送音频数据帧。如果第一帧就发送音频数据，服务端会直接返回EOF。
• Golang实现中建议用channel做同步：先发送配置帧，收到服务端的ACK之后再启动协程将audiofork推送的音频帧写入gRPC流，避免音频数据提前发送。

3. 修复流发送逻辑的并发问题 #

• Golang的gRPC客户端流非并发安全，如果多协程同时往同一个StreamingRecognizeClient写入数据，会导致流数据乱序、损坏，触发EOF错误。必须加互斥锁保证同一时间只有一个协程执行流写入操作。
• 不要攒超过100ms的音频帧一次性发送，也不要拆分单帧到小于10ms的大小，谷歌服务建议单次发送的音频帧时长在10~100ms范围内，和audiofork默认的20ms帧大小刚好匹配，直接透传单帧即可。

4. 调整gRPC客户端配置 #

• 调大WithSendMsgSize参数到至少1MB，避免音频帧被截断导致连接断开。
• 不要设置过短的空闲超时时间，流式识别为长连接，建议将WithIdleTimeout设置为大于通话最大时长的值。
• 先拿本地保存的音频文件调用非流式Recognize接口测试，如果非流式接口可以正常返回识别结果，即可排除凭证权限、音频本身损坏的问题，聚焦排查流式逻辑即可。

内容的提问来源于stack exchange，提问作者camilos