PCM 音频调试器实战指南用单文件 HTML 生成与回放 Base64 PCM 音频流Gemini Multimodal Live API 配套工具【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-aiPCM脉冲编码调制是 Gemini Multimodal Live API 这类低延迟双向音频流场景中最基础的音频承载格式麦克风采集的原始采样数据必须被编码成 16-bit 小端 PCM再经 Base64 包装后通过 WebSocket 上传模型返回的音频同样以 Base64 PCM 的形式在server_content中下发。pcm-audio-debugger正是为此准备的零依赖单文件调试工具集「录音→Base64 PCM 生成器」与「Base64 PCM 多包解码回放器」于一体。读完本文你将掌握该工具两个标签页的完整操作流程、底层编码/解码算法原理以及它在整个仓库 Multimodal Live API 生态中的典型调试场景。工具定位为什么需要独立的 PCM 调试器在 Multimodal Live API 目录 的 Tools 一节中官方将 PCM Audio Debugger 描述为用于测试和调试原始 PCM 音频流以及 WebSocket 连接的独立工具。它解决的核心问题是验证格式假设Multimodal Live API 对音频格式有严格规定——输入为16-bit 小端 PCM、16kHz输出为16-bit 小端 PCM、24kHz见 intro_multimodal_live_api.ipynb 中的Audio Streaming一节。当你从 WebSocket 抓到一段 Base64 数据却听不到声音时首先要判断是采样率、声道数还是位深不匹配。生成可控输入用真实麦克风录制并转换成指定格式的 Base64 PCM用于测试流式上传逻辑。回放验证输出把模型返回的 Base64 PCM 粘贴进来直接播放快速确认数据链路是否正常。整个工具只有两个文件README.md使用说明与 pcm-audio-debugger.html 单文件实现页面标题为 PCM Debugging SuiteUI 通过 Tailwind CDN 与 Lucide 图标渲染逻辑全部内联在页面底部的两个 IIFE 中。特性总览工具核心特性与 README 声明一致可归纳为三点零依赖整个工具就是一个 HTML 文件在任意现代浏览器Chrome、Edge、Firefox、Safari中直接双击打开即可使用无需安装任何包或启动服务器。唯一的前置条件是浏览器支持 Web Audio API 与getUserMedia需要 HTTPS 或 localhost 环境才能授权麦克风。PCM 生成器录制麦克风输入并转换为 Base64 编码的 PCM 数据支持 8kHz–48kHz 多种采样率、单声道/立体声、8-bit无符号、16-bit有符号小端、32-bit浮点小端三种位深/格式。多包播放器解码并回放 Base64 PCM 字符串支持粘贴多个顺序数据包以模拟流式音频场景并可根据数据格式与采样率自适应播放。用 PCM Generator 生成 Base64 PCM操作步骤用浏览器打开pcm-audio-debugger.html。切换到PCM Generator标签页页面默认即为此页。在Select Microphone下拉框中选择目标麦克风首次访问浏览器会弹出麦克风权限请求必须先允许。配置三个目标格式参数Target Sample Rate目标采样率、Target Channels目标声道数、Target Bit Depth / Format目标位深/格式。点击Record开始录音对着麦克风说话再点击Stop停止。录音结束后页面自动处理编码Base64 PCM Output文本框内出现 Base64 字符串点击Copy to Clipboard复制。参数选项与默认值三个下拉框的具体取值与 HTML 中option一一对应参数可选值默认值Target Sample Rate8000、16000、22050、24000、32000、44100、48000 Hz16000Target Channels1 (Mono)、2 (Stereo)1 (Mono)Target Bit Depth / Format8u8-bit 无符号整型、16s16-bit 有符号整型小端、32f32-bit 浮点小端16s默认值 16000 Hz Mono 16-bit 有符号小端恰好与 Multimodal Live API 的输入音频规格16-bit PCM 16kHz 小端一致是最常用的调试起点。底层实现原理从 pcm-audio-debugger.html 的 GENERATOR LOGIC 部分约 L365-L746可以还原完整的数据链路设备枚举页面加载时调用navigator.mediaDevices.getUserMedia({audio: true})申请权限随后用enumerateDevices()过滤出kind audioinput的设备填充下拉框还监听了devicechange事件热插拔麦克风会自动刷新列表。录音点击 Record 后用目标采样率创建AudioContext({ sampleRate: targetSampleRate })通过createMediaStreamSource接入麦克风流再用ScriptProcessorNodebufferSize 4096按块捕获Float32Array格式的样本每块推入recordedChunks数组。状态区会实时显示实际录音采样率与实际声道数从audioTrack.getSettings().channelCount读取。声道转换编码前会根据目标声道数做转换——单声道→立体声时直接复制一份数据立体声→单声道时取两声道平均值(L R) / 2相同时原样保留。随后做交错interleave合并为单流。位深编码8u8-bit 无符号Math.round((sample 1) * 127.5)即把[-1, 1]映射到[0, 255]16s16-bit 有符号小端Math.round(sample * 32767)写入Int16Array32f32-bit 浮点小端直接以Float32Array输出。 编码前都会先将样本Math.max(-1, Math.min(1, ...))限幅到合法范围。Base64 化arrayBufferToBase64将字节数组逐字节转成二进制字符串后交给window.btoa()得到可直接粘贴、传输的 Base64 字符串。一个值得注意的实现细节工具未实现重采样。如果浏览器实际输出采样率audioContext.sampleRate与下拉框选择的目标值不一致多数浏览器对AudioContext({sampleRate})只会就近取整或直接忽略状态区会弹出警告Output sample rate is X Hz, not Y Hz as resampling is not implemented。因此生成结果的真实采样率以状态区显示的(Recording at X Hz)为准不要盲目相信下拉框数值。用 Packet Player 回放 Base64 PCM操作步骤切换到Packet Player标签页。将 Base64 PCM 字符串粘贴进文本区第一个输入框占位提示为 Paste Base64 packet 1 here...。可选点击Add Packet追加更多文本区粘贴多个顺序数据段每条数据右侧有垃圾桶按钮可单独删除。确认播放设置与数据匹配Sample Rate数字输入框默认 24000、Channels默认 Mono、Bit Depth / Format默认 16-bit 有符号小端。点击Decode Play All Packets一次性解码并连续播放所有数据包。多包合并解码原理PLAYER LOGIC 部分约 L751-L988的核心是decodeAndPrepareAudio()Base64 解码对每个非空文本区依次atob()解码为字节数组累计总字节数后合并成一个大Uint8Array任一数据包 Base64 非法都会抛出Invalid Base64 in packet N错误并中止。格式解析按位深确定bytesPerSample8u1、16s2、32f4结合声道数算出frameCount totalSamples / numChannels用audioContext.createBuffer(channels, frameCount, sampleRate)创建目标音频缓冲。样本还原使用DataView以小端序逐样本读取8u(getUint8(offset) - 128) / 128.0把无符号 8-bit 还原回[-1, 1]16sgetInt16(offset, true) / 32768.032fgetFloat32(offset, true)。 每个样本再经Math.max(-1, Math.min(1, ...))限幅后写入对应声道。播放playAudioBuffer()用AudioBufferSourceNode播放合并后的缓冲onended回调会报告总时长Playback finished. Duration: X.XXs。如果上一次播放尚未结束会先stop()旧 source 再播放新数据。多包合并播放的意义在于还原真实流式场景Gemini 模型回复的音频通常被拆成多个inline_data块依次抵达把整条回复的全部块按顺序粘贴进来即可一次性听到完整内容并核对总时长是否符合预期。在 Multimodal Live API 调试中的实际用法校验输入侧16kHz PCM16Multimodal Live API 要求输入音频为raw 16-bit PCM 16kHz、小端。用生成器录制时选择 16000 Hz Mono 16s得到的 Base64 即可直接作为realtime_input.media_chunks[].data上传。仓库中 intro_multimodal_live_api.ipynb 展示了标准上传格式msg { realtime_input: { media_chunks: [ { mime_type: audio/pcm;rate16000, data: base64.b64encode(chunk).decode(utf-8), } ] } }Python SDK 侧gemini_live.py等价实现为session.send_realtime_input(audiotypes.Blob(datachunk, mime_typefaudio/pcm;rate{input_sample_rate}))其中input_sample_rate同样为 16000。校验输出侧24kHz PCM16模型回复的音频出现在server_content.model_turn.parts[].inline_data中是24kHz 的 16-bit 小端 PCM。把从inlineData.data取出的 Base64 直接粘贴进 Packet Player将 Sample Rate 设为24000、Channels 设为 Mono、Bit Depth 设为 16s即可听到 Gemini 的实际语音输出。对照解码循环if inlineData in part: pcm_data base64.b64decode(part[inlineData][data]) audio_data.append(np.frombuffer(pcm_data, dtypenp.int16))如果播放时出现音调异常偏高或偏低或速度异常往往是采样率填错出现明显噪音则要检查位深/字节序是否匹配——这正是该调试器的价值所在。与仓库内其他音频实现相互印证仓库内的生产级示例使用同一套 PCM 约定可作为调试结果的参照plain-js-demo-app 的 mediaUtils.js 中AudioStreamer固定sampleRate 16000Gemini requires 16kHzconvertToPCM16用sample * 0x7fff完成 Float32→Int16 的编码——与调试器 16s 分支的sample * 32767属同一算法。同目录的 playback.worklet.js 中PCMProcessor维护音频队列并按需填充输出缓冲AudioPlayer则固定sampleRate 24000Gemini outputs at 24kHz并用inputArray[i] / 32768还原 Float32 样本——与调试器 16s 解码公式getInt16 / 32768.0完全对应。由此可以推断调试器的三个位深选项恰好覆盖了实时音频链路中最常见的三种形态8u 多见于嵌入式/低功耗设备传输16s 是 Gemini Live API 的标准规格32f 则用于需要保持浮点精度的处理管线。常见问题与排障建议没有麦克风选项页面要求浏览器授予麦克风权限且环境需为 HTTPS 或 localhost在http://明文页面上getUserMedia会被拒绝浏览器控制台会输出Generator: Error getting permissions。生成的 Base64 采样率不对状态区出现 resampling is not implemented 警告时以(Recording at X Hz)显示的实际采样率为准若需精确的 16kHz建议选择系统录音设备原生采样率或后续自行重采样。播放无声音先核对三项播放设置是否与数据匹配再确认音频输出设备未被静音Web Audio 要求用户手势后才会启动点击Decode Play All Packets本身就是解锁手势。粘贴多个包仍无法播放检查每个包是否都是合法 Base64错误信息会精确到packet N并确认各包使用相同采样率、声道数与位深。小结pcm-audio-debugger用最朴素的方式一个 HTML 文件补全了 Multimodal Live API 调试链路中最易出错的一环——原始 PCM 数据的生成与回放。它既是独立工具也是理解 playback.worklet.js 等生产级音频处理代码的最佳对照参考掌握了 8u/16s/32f 三种位深的双向转换、16kHz/24kHz 的输入输出规格以及 Base64 包装规则你就能在 WebSocket 抓包、录音上传、音频回放等任何环节快速定位并隔离问题。【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 16:22:58 · 阅读 1.2k PCM 音频调试器实战指南：用单文件 HTML 生成与回放 Base64 PCM 音频流（Gemini Multimodal Live API 配套工具）
PCM 音频调试器实战指南用单文件 HTML 生成与回放 Base64 PCM 音频流Gemini Multimodal Live API 配套工具【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-aiPCM脉冲编码调制是 Gemini Multimodal Live API 这类低延迟双向音频流场景中最基础的音频承载格式麦克风采集的原始采样数据必须被编码成 16-bit 小端 PCM再经 Base64 包装后通过 WebSocket 上传模型返回的音频同样以 Base64 PCM 的形式在server_content中下发。pcm-audio-debugger正是为此准备的零依赖单文件调试工具集「录音→Base64 PCM 生成器」与「Base64 PCM 多包解码回放器」于一体。读完本文你将掌握该工具两个标签页的完整操作流程、底层编码/解码算法原理以及它在整个仓库 Multimodal Live API 生态中的典型调试场景。工具定位为什么需要独立的 PCM 调试器在 Multimodal Live API 目录 的 Tools 一节中官方将 PCM Audio Debugger 描述为用于测试和调试原始 PCM 音频流以及 WebSocket 连接的独立工具。它解决的核心问题是验证格式假设Multimodal Live API 对音频格式有严格规定——输入为16-bit 小端 PCM、16kHz输出为16-bit 小端 PCM、24kHz见 intro_multimodal_live_api.ipynb 中的Audio Streaming一节。当你从 WebSocket 抓到一段 Base64 数据却听不到声音时首先要判断是采样率、声道数还是位深不匹配。生成可控输入用真实麦克风录制并转换成指定格式的 Base64 PCM用于测试流式上传逻辑。回放验证输出把模型返回的 Base64 PCM 粘贴进来直接播放快速确认数据链路是否正常。整个工具只有两个文件README.md使用说明与 pcm-audio-debugger.html 单文件实现页面标题为 PCM Debugging SuiteUI 通过 Tailwind CDN 与 Lucide 图标渲染逻辑全部内联在页面底部的两个 IIFE 中。特性总览工具核心特性与 README 声明一致可归纳为三点零依赖整个工具就是一个 HTML 文件在任意现代浏览器Chrome、Edge、Firefox、Safari中直接双击打开即可使用无需安装任何包或启动服务器。唯一的前置条件是浏览器支持 Web Audio API 与getUserMedia需要 HTTPS 或 localhost 环境才能授权麦克风。PCM 生成器录制麦克风输入并转换为 Base64 编码的 PCM 数据支持 8kHz–48kHz 多种采样率、单声道/立体声、8-bit无符号、16-bit有符号小端、32-bit浮点小端三种位深/格式。多包播放器解码并回放 Base64 PCM 字符串支持粘贴多个顺序数据包以模拟流式音频场景并可根据数据格式与采样率自适应播放。用 PCM Generator 生成 Base64 PCM操作步骤用浏览器打开pcm-audio-debugger.html。切换到PCM Generator标签页页面默认即为此页。在Select Microphone下拉框中选择目标麦克风首次访问浏览器会弹出麦克风权限请求必须先允许。配置三个目标格式参数Target Sample Rate目标采样率、Target Channels目标声道数、Target Bit Depth / Format目标位深/格式。点击Record开始录音对着麦克风说话再点击Stop停止。录音结束后页面自动处理编码Base64 PCM Output文本框内出现 Base64 字符串点击Copy to Clipboard复制。参数选项与默认值三个下拉框的具体取值与 HTML 中option一一对应参数可选值默认值Target Sample Rate8000、16000、22050、24000、32000、44100、48000 Hz16000Target Channels1 (Mono)、2 (Stereo)1 (Mono)Target Bit Depth / Format8u8-bit 无符号整型、16s16-bit 有符号整型小端、32f32-bit 浮点小端16s默认值 16000 Hz Mono 16-bit 有符号小端恰好与 Multimodal Live API 的输入音频规格16-bit PCM 16kHz 小端一致是最常用的调试起点。底层实现原理从 pcm-audio-debugger.html 的 GENERATOR LOGIC 部分约 L365-L746可以还原完整的数据链路设备枚举页面加载时调用navigator.mediaDevices.getUserMedia({audio: true})申请权限随后用enumerateDevices()过滤出kind audioinput的设备填充下拉框还监听了devicechange事件热插拔麦克风会自动刷新列表。录音点击 Record 后用目标采样率创建AudioContext({ sampleRate: targetSampleRate })通过createMediaStreamSource接入麦克风流再用ScriptProcessorNodebufferSize 4096按块捕获Float32Array格式的样本每块推入recordedChunks数组。状态区会实时显示实际录音采样率与实际声道数从audioTrack.getSettings().channelCount读取。声道转换编码前会根据目标声道数做转换——单声道→立体声时直接复制一份数据立体声→单声道时取两声道平均值(L R) / 2相同时原样保留。随后做交错interleave合并为单流。位深编码8u8-bit 无符号Math.round((sample 1) * 127.5)即把[-1, 1]映射到[0, 255]16s16-bit 有符号小端Math.round(sample * 32767)写入Int16Array32f32-bit 浮点小端直接以Float32Array输出。 编码前都会先将样本Math.max(-1, Math.min(1, ...))限幅到合法范围。Base64 化arrayBufferToBase64将字节数组逐字节转成二进制字符串后交给window.btoa()得到可直接粘贴、传输的 Base64 字符串。一个值得注意的实现细节工具未实现重采样。如果浏览器实际输出采样率audioContext.sampleRate与下拉框选择的目标值不一致多数浏览器对AudioContext({sampleRate})只会就近取整或直接忽略状态区会弹出警告Output sample rate is X Hz, not Y Hz as resampling is not implemented。因此生成结果的真实采样率以状态区显示的(Recording at X Hz)为准不要盲目相信下拉框数值。用 Packet Player 回放 Base64 PCM操作步骤切换到Packet Player标签页。将 Base64 PCM 字符串粘贴进文本区第一个输入框占位提示为 Paste Base64 packet 1 here...。可选点击Add Packet追加更多文本区粘贴多个顺序数据段每条数据右侧有垃圾桶按钮可单独删除。确认播放设置与数据匹配Sample Rate数字输入框默认 24000、Channels默认 Mono、Bit Depth / Format默认 16-bit 有符号小端。点击Decode Play All Packets一次性解码并连续播放所有数据包。多包合并解码原理PLAYER LOGIC 部分约 L751-L988的核心是decodeAndPrepareAudio()Base64 解码对每个非空文本区依次atob()解码为字节数组累计总字节数后合并成一个大Uint8Array任一数据包 Base64 非法都会抛出Invalid Base64 in packet N错误并中止。格式解析按位深确定bytesPerSample8u1、16s2、32f4结合声道数算出frameCount totalSamples / numChannels用audioContext.createBuffer(channels, frameCount, sampleRate)创建目标音频缓冲。样本还原使用DataView以小端序逐样本读取8u(getUint8(offset) - 128) / 128.0把无符号 8-bit 还原回[-1, 1]16sgetInt16(offset, true) / 32768.032fgetFloat32(offset, true)。 每个样本再经Math.max(-1, Math.min(1, ...))限幅后写入对应声道。播放playAudioBuffer()用AudioBufferSourceNode播放合并后的缓冲onended回调会报告总时长Playback finished. Duration: X.XXs。如果上一次播放尚未结束会先stop()旧 source 再播放新数据。多包合并播放的意义在于还原真实流式场景Gemini 模型回复的音频通常被拆成多个inline_data块依次抵达把整条回复的全部块按顺序粘贴进来即可一次性听到完整内容并核对总时长是否符合预期。在 Multimodal Live API 调试中的实际用法校验输入侧16kHz PCM16Multimodal Live API 要求输入音频为raw 16-bit PCM 16kHz、小端。用生成器录制时选择 16000 Hz Mono 16s得到的 Base64 即可直接作为realtime_input.media_chunks[].data上传。仓库中 intro_multimodal_live_api.ipynb 展示了标准上传格式msg { realtime_input: { media_chunks: [ { mime_type: audio/pcm;rate16000, data: base64.b64encode(chunk).decode(utf-8), } ] } }Python SDK 侧gemini_live.py等价实现为session.send_realtime_input(audiotypes.Blob(datachunk, mime_typefaudio/pcm;rate{input_sample_rate}))其中input_sample_rate同样为 16000。校验输出侧24kHz PCM16模型回复的音频出现在server_content.model_turn.parts[].inline_data中是24kHz 的 16-bit 小端 PCM。把从inlineData.data取出的 Base64 直接粘贴进 Packet Player将 Sample Rate 设为24000、Channels 设为 Mono、Bit Depth 设为 16s即可听到 Gemini 的实际语音输出。对照解码循环if inlineData in part: pcm_data base64.b64decode(part[inlineData][data]) audio_data.append(np.frombuffer(pcm_data, dtypenp.int16))如果播放时出现音调异常偏高或偏低或速度异常往往是采样率填错出现明显噪音则要检查位深/字节序是否匹配——这正是该调试器的价值所在。与仓库内其他音频实现相互印证仓库内的生产级示例使用同一套 PCM 约定可作为调试结果的参照plain-js-demo-app 的 mediaUtils.js 中AudioStreamer固定sampleRate 16000Gemini requires 16kHzconvertToPCM16用sample * 0x7fff完成 Float32→Int16 的编码——与调试器 16s 分支的sample * 32767属同一算法。同目录的 playback.worklet.js 中PCMProcessor维护音频队列并按需填充输出缓冲AudioPlayer则固定sampleRate 24000Gemini outputs at 24kHz并用inputArray[i] / 32768还原 Float32 样本——与调试器 16s 解码公式getInt16 / 32768.0完全对应。由此可以推断调试器的三个位深选项恰好覆盖了实时音频链路中最常见的三种形态8u 多见于嵌入式/低功耗设备传输16s 是 Gemini Live API 的标准规格32f 则用于需要保持浮点精度的处理管线。常见问题与排障建议没有麦克风选项页面要求浏览器授予麦克风权限且环境需为 HTTPS 或 localhost在http://明文页面上getUserMedia会被拒绝浏览器控制台会输出Generator: Error getting permissions。生成的 Base64 采样率不对状态区出现 resampling is not implemented 警告时以(Recording at X Hz)显示的实际采样率为准若需精确的 16kHz建议选择系统录音设备原生采样率或后续自行重采样。播放无声音先核对三项播放设置是否与数据匹配再确认音频输出设备未被静音Web Audio 要求用户手势后才会启动点击Decode Play All Packets本身就是解锁手势。粘贴多个包仍无法播放检查每个包是否都是合法 Base64错误信息会精确到packet N并确认各包使用相同采样率、声道数与位深。小结pcm-audio-debugger用最朴素的方式一个 HTML 文件补全了 Multimodal Live API 调试链路中最易出错的一环——原始 PCM 数据的生成与回放。它既是独立工具也是理解 playback.worklet.js 等生产级音频处理代码的最佳对照参考掌握了 8u/16s/32f 三种位深的双向转换、16kHz/24kHz 的输入输出规格以及 Base64 包装规则你就能在 WebSocket 抓包、录音上传、音频回放等任何环节快速定位并隔离问题。【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考