基于C# MVC Web应用借助Google Speech-to-Text API捕获麦克风实时音频转写的疑问

核心要解决三个核心矛盾：浏览器独占麦克风设备访问权限、Google Speech API的鉴权安全、低延迟实时转写体验。整体拆分为三层链路，完全匹配C# MVC的架构特性：

• 浏览器端全权负责麦克风权限申请、音频实时采集、格式标准化处理
• C# MVC服务端全权负责Google Speech API的鉴权、流转发、用户身份校验、接口调用权限管控
• 通过WebSocket建立双向长连接，打通前端音频上行、识别结果下行的全链路，避免HTTP短连接带来的高延迟

服务端（C# MVC）搭建 #

• 在项目的安全配置存储中（比如用户机密、环境变量）保存Google Speech API的服务账号密钥，绝对不要把密钥文件放到静态资源目录，也不要硬编码到代码中提交到版本库
• 给项目启用WebSocket支持：.NET Framework MVC直接依托内置的System.Web.WebSockets能力实现长连接接收，.NET Core MVC直接启用原生WebSocket中间件即可，不需要额外引入重型通信框架
• 编写WebSocket连接的核心处理逻辑：
  • 连接建立时先校验当前登录用户的身份，拒绝匿名用户的连接请求
  • 接收前端分片上传的标准化音频块，逐块转发到对应匹配的Google Speech实时识别会话中，提前配置好识别参数：16kHz单声道PCM编码、开启临时结果实时返回、指定识别语种、启用自动标点
  • 接收到Google Speech返回的识别结果后，直接通过当前WebSocket连接推回给发起请求的前端
  • 连接断开时主动销毁对应的Google识别会话，及时释放接口配额
  • 增加连接限流逻辑：单个用户同一时间最多可建立2个识别连接，避免恶意刷量导致API额度耗尽

前端页面实现 #

• 页面中增加语音输入的触发按钮，点击后通过浏览器原生getUserMediaAPI申请麦克风权限：这里必须注意，该API仅在HTTPS环境或localhost本地开发环境下可用，生产部署必须配置站点HTTPS，否则权限申请会直接被浏览器拦截
• 拿到音频流后，通过内置的音频处理能力把原始音频重采样为16kHz单声道的线性PCM格式，按照每150ms为一个分片的粒度，把音频块通过WebSocket发送给MVC服务端，不要攒大块音频再传输，否则会明显拉高实时延迟
• 接收服务端推送的识别结果：如果是临时识别结果，以浅色预览文本的形式展示在输入框中；如果是最终定稿的识别结果，替换预览文本为正式可编辑内容，用户可以随时手动修改转写后的文本

• 不要把浏览器默认采集的44.1kHz采样率音频直接上传，过高的采样率会大幅增加音频传输带宽，同时拉高Google接口的转写延迟，统一调整为16kHz是兼顾准确率和实时性的最优选择
• 不要尝试绕过服务端直接在前端调用Google Speech API，前端硬编码的服务账号密钥很容易被爬虫获取，产生不可控的API账单损失
• 不要用普通HTTP接口做整段音频上传的模式实现所谓“实时转写”，攒段上传的模式会导致几百ms甚至数秒的延迟，完全达不到边说边出字的流畅体验

内容的提问来源于stack exchange，提问作者Ragesh Puthiyedath Raju