ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

用 Gemini Live API 实现实时音频对话:本地麦克风接入的实战

用 Gemini Live API 实现实时音频对话:本地麦克风接入的实战 用 Gemini Live API 实现实时音频对话本地麦克风接入的实战【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbookcookbook 是 Gemini API 的官方示例仓库这篇文章只聚焦一件事用 Gemini Live API 把本地麦克风的音频实时喂给模型并当场听到它的语音回答。核心脚本在 quickstarts/ 下最短的一份就是Get_started_LiveAPI_NativeAudio.py不到 200 行能完整跑通说话—听回答—随时打断的闭环。从录一段发一段到边说边答如果你做过语音助手原型大概率卡在这个地方说一句话等好几秒才回音。普通聊天接口是请求-响应模式音频得录完整、传完整模型处理完才返回。Live API 是一条双向 WebSocket 会话麦克风的音频分小块持续往上推模型生成的音频也持续往下流两边同时进行延迟被压到接近人对话的水平。能力说明在哪看实时音频流麦克风 PCM 分块上传模型 PCM 分块回传边说边答quickstarts/Get_started_LiveAPI_NativeAudio.py双向打断你说话时模型停嘴模型被要求继续时也能抢话同上proactivity配置多模态输入同一条会话里加摄像头或屏幕画面每秒一帧quickstarts/Get_started_LiveAPI.py转写回显你说的话、模型说的话都以文本同步打印到终端同上input_audio_transcription边界也说清楚这套接口不是离线部署需要稳定的网络长连接音频格式是裸 PCM不做 mp3 之类的压缩打断和主动回应依赖模型侧的支持换到不认识的模型上行为可能退化。装好依赖把麦克风接上跑通只需要两件事装包、设 key。pip install google-genai pyaudio export GEMINI_API_KEY你的keymacOS 上要先brew install portaudioPython 低于 3.11 还要补一个taskgroup包。这些脚本在仓库头部注释里都写明了照着抄就行。一条 Live 会话加四个任务看Get_started_LiveAPI_NativeAudio.py的run()方法骨架是这样的async with client.aio.live.connect(modelMODEL, configCONFIG) as session, \ asyncio.TaskGroup() as tg: tg.create_task(self.listen_audio()) # 麦克风 tg.create_task(self.send_realtime()) # 上传 tg.create_task(self.receive_audio()) # 下载 tg.create_task(self.play_audio()) # 播放为什么是四个任务而不是一个函数从头写到尾因为麦克风的采集、网络发送、网络接收、声卡播放各自有独立的节奏互相不能阻塞。四个任务之间靠两个队列传递数据out_queue放待上传的音频块audio_in_queue放待播放的音频块。先让这四条流水线转起来再去想优化。跑起来之后对着麦克风说话终端会实时打印模型转写的文字。听到回音就说明链路通了。改三处换模型、换人设跑通之后值得动的地方不多按性价比排序换MODEL。脚本默认是gemini-2.5-flash-native-audio-preview-12-2025这是为原生音频优化的 preview 模型想对比效果可以换 quickstarts/websockets/Get_started_LiveAPI.py 里用的gemini-2.5-flash-native-audio-latest。改system_instruction。里面那段语气友好、结尾抛一个跟进问题的提示词直接决定它说话的风格改成简洁的客服试试差别很明显。开转写和上下文压缩。完整版脚本 quickstarts/Get_started_LiveAPI.py 里配置了input_audio_transcription/output_audio_transcription长对话不会越聊越偏还加了context_window_compression滑窗。采样率必须分开写真正影响效果的就三个参数其余基本不用碰。两个采样率方向不同。SEND_SAMPLE_RATE 16000是你上传的 PCM 采样率RECEIVE_SAMPLE_RATE 24000是模型返回音频的采样率。开麦克风时填 16000开播放时填 24000两边各写各的。把两个流混用一个采样率声音会出现变调、加速这类症状排查半天其实是个参数填反了。CHUNK_SIZE控制每次读多少帧。脚本里是 1024 帧按 16kHz 算大约 64ms 一块。太小会增加 I/O 次数太大则每块要攒够才能发延迟变高。一般保持原值。输出队列的maxsize5。这是个背压机制队列只留 5 块缓冲。音频是实时数据积压的旧块没有播放价值丢比留好。完整版脚本做得更直接队列满时丢掉最旧的一块再放新的就是为了保实时性。CONFIG里还有proactivity: {proactive_audio: True}这一项控制模型是否可以不等你开口就主动插话比如你停顿思考时它接上一句。关掉就变成严格的你问我答模式。不戴耳机它会和自己抢话现象模型刚开口就被打断然后你听到一段残缺的回答接着它又突然接上来回拉扯。原因系统默认麦克风和扬声器之间没有回声消除喇叭里它自己的声音被麦克风收回去模型当成新的人声输入于是判定用户打断了。绕开方式戴耳机。脚本头部注释里专门用加粗提醒了这件事不是客套话。现象你打断它之后旧的回答还在继续播得等播完才轮到你。原因下载和播放是两个独立任务模型那边已经停了但audio_in_queue里可能还压着十几块没播完的音频。绕开方式收到模型的turn_complete信号时把播放队列整个清空。两个脚本里都有这段 while 循环别删。现象macOS 上import pyaudio直接报错提示 PortAudio 找不到。原因PyAudio 只是封装底层依赖 PortAudio 这个 C 库。绕开方式brew install portaudio再装 pyaudio。想看协议细节或者想接摄像头想搞清楚 SDK 底下到底发了什么去 quickstarts/websockets/ 看Get_started_LiveAPI.py它不用 SDK直接用 WebSocket 连generativelanguage.googleapis.com的 wss 端点手动发setup消息、手动拼realtime_input帧协议结构一目了然。看完再回头看 SDK 版本心里就有底了。想加视频输入Get_started_LiveAPI.py支持--mode camera或--mode screen每秒抓一帧图推进同一条会话模型可以看着屏幕和你说话还能在对话中调工具示例在 quickstarts/websockets/Get_started_LiveAPI_tools.ipynb。再往硬件方向走一步examples/iot/esp32/voice_led_controller/ 用 ESP32 加麦克风模块录音把音频发回 Gemini 再用 function calling 控制 LED 灯环是另一条把语音落到实物的路子。下一步建议先把Get_started_LiveAPI_NativeAudio.py在耳机状态下完整跑通一轮对话再打开Get_started_LiveAPI.py对比多模态配置两边的差异就是你要学的全部。【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表