FastRTC项目：实现同时支持文本与音频输入的WebRTC处理方案

背景与需求分析

在基于WebRTC的实时通信应用中，FastRTC项目提供了一个强大的框架来处理音频流。然而，在实际应用场景中，开发者经常需要同时处理文本和音频两种输入方式。这种需求主要来自以下场景：

1. 用户可能在某些情况下更倾向于使用文本输入而非语音
2. 调试过程中，文本输入可以跳过语音识别(STT)步骤，显著提高开发效率
3. 需要支持混合交互模式的应用场景

技术挑战

当前FastRTC的ReplyOnPause机制存在两个主要限制：

1. 处理函数只能接收音频输入，无法直接获取前端发送的文本数据
2. 响应逻辑仅在检测到语音暂停时触发，缺乏手动触发的机制

解决方案实现

混合输入处理方案

通过扩展FastRTC的处理能力，可以实现同时支持文本和音频输入的混合处理模式。核心思路如下：

def echo(audio, text):
    if text:  # 优先处理文本输入
        prompt = text
    else:  # 处理音频输入
        audio_bytes = audio_to_bytes(audio)
        prompt = my_stt_client.transcribe(audio_bytes)
    
    # 后续处理逻辑
    response = llm_client.chat.completions.create(
        model="Meta-Llama-3.2-3B-Instruct",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=200,
    )
    return response.choices[0].message.content

自定义前端集成方案

对于使用自定义前端的开发者，可以通过创建专门的API端点来实现文本输入的注入：

from pydantic import BaseModel

class InputData(BaseModel):
    webrtc_id: str
    textbox_content: str

@app.post("/input_hook")
async def handle_text_input(body: InputData):
    stream.set_input(body.webrtc_id, body.textbox_content)
    return {"status": "ok"}

主动触发机制

为解决ReplyOnPause必须依赖语音暂停检测的限制，可以扩展其功能，增加主动触发响应的能力：

@app.post("/trigger_response")
async def trigger_handler(body: InputData):
    stream.set_input(body.webrtc_id, body.textbox_content)
    stream.handlers[body.webrtc_id].trigger_response()
    return {"status": "ok"}

应用场景与优势

这种混合输入处理方案特别适合以下场景：

1. 多模态交互应用：用户可以根据场景自由选择语音或文本输入
2. 开发调试：通过文本输入快速测试语音识别后的处理逻辑
3. 无障碍应用：为有语言障碍的用户提供替代输入方式
4. 嘈杂环境：在背景噪声大的场合使用文本输入确保准确性

实现建议与最佳实践

1. 输入优先级设计：建议实现文本输入优先策略，当同时收到文本和音频时优先处理文本
2. 状态管理：确保在处理混合输入时维护好对话上下文状态
3. 错误处理：为文本和音频输入分别设计适当的错误处理机制
4. 性能优化：对于高频文本输入场景，考虑实现批处理机制

未来扩展方向

1. 支持更丰富的输入类型（如图片、视频等）
2. 实现输入类型的自动检测和路由
3. 开发内置的混合输入管理组件
4. 提供输入转换功能（如将文本转换为语音输出）

这种增强的WebRTC处理方案为开发者提供了更大的灵活性，能够满足更复杂的实时通信应用需求，同时保持FastRTC原有的简洁性和高效性。