人工智能语音模型推理服务深度学习【免费下载链接】voice-changerリアルタイムボイスチェンジャー Realtime Voice Changer项目地址https://gitcode.com/gh_mirrors/vo/voice-changer点击查看免费下载本文围绕 Realtime Voice Changer 官方教程 tutorials/tutorial_device_mode_ko.md韩文版另有 日文版展开系统讲解自 v1.5.2.9 起引入的两种设备模式——由浏览器Chrome控制麦克风/扬声器的 client device mode以及由 VC Client 进程直接操控 PC 音频设备的 server device mode。你将理解两者的数据通路差异、优缺点边界并通过仓库源码看清 server device mode 的设备枚举、采样率校验、独占模式与三种运行布局的实现细节最终能够根据自身场景正确选择并配置设备模式。从 v1.5.2.9 说起两种设备模式的分界线Realtime Voice Changer 的设备模式演进以版本 v1.5.2.9 为界v1.5.2.9 之前系统只存在一种构成方式——由浏览器Chrome控制麦克风和扬声器通过浏览器捕获的音频流完成语音变换。这种模式被称为client device mode。v1.5.2.9 之后新增了一种模式——由 VC Client服务端进程直接控制连接到 PC 的麦克风和扬声器来完成语音变换。这种模式被称为server device mode。此后两种模式并存用户可在界面上选择其一。从客户端源码可以印证 client device mode 的通路在 client/lib/src/VoiceChangerClient.ts 中客户端通过navigator.mediaDevices.getUserMedia获取麦克风流再以AudioContext.createMediaStreamSource接入音频图经 VoiceChangerWorkletNodeAudioWorklet 节点处理后由createMediaStreamDestination()生成的输出节点送向浏览器扬声器。整条链路完全运行在浏览器Web Audio API内部这是 client device mode 的本质。client device mode浏览器接管麦克风与扬声器client device mode 的核心理念是把麦克风/扬声器的复杂处理交给浏览器。从实现上看输入侧getUserMedia负责打开麦克风并可通过约束条件constraints控制采样率、通道数等见 VoiceChangerClient.ts处理侧语音变换由 AudioWorkletVoiceChangerWorkletNode在浏览器音频线程内完成输出侧变换后的音频经MediaStreamDestination送到浏览器默认扬声器。对应官方教程client device mode 的优点与缺点如下优点缺点1. Chrome 代劳了麦克风/扬声器的诸多复杂处理1. 多少会有延迟增加2. 可以使用 Chrome 内置的 Web 会议功能如噪声消除等也就是说如果你依赖 Chrome 提供的回声消除、噪声抑制等会议能力或希望浏览器自动处理设备兼容问题client device mode 是顺手的默认选择代价是端到端延迟相对更高。server device modeVC Client 直接控制音频设备server device mode 的核心理念是绕过浏览器由 VC Client服务端 Python 进程直接操控连接在 PC 上的麦克风和扬声器。其优点与缺点如下优点缺点1. VC Client 直接处理麦克风/扬声器延迟更低1. 可能存在无法处理的麦克风/扬声器2. 无法使用 Chrome 的便利功能如噪声消除等用户可以根据各自的优缺点区分使用两种模式官方教程原话。简言之server device mode 以“更低的延迟”换取“更少的浏览器便利功能与更大的设备兼容性风险”。server device mode 底层实现源码级解析server device mode 在服务端的实现主体是 server/voice_changer/Local/ServerDevice.py其依赖 sounddevicePortAudio 的 Python 绑定直接与系统音频设备交互。设备枚举与信息上报server/voice_changer/Local/AudioDeviceList.py 中的list_audio_device()使用sd.query_devices()枚举系统设备按max_input_channels 0与max_output_channels 0分别划分输入、输出设备并结合sd.query_hostapis()获取每个设备的 Host API 名称最终返回ServerAudioDevice列表包含 kind、index、name、hostAPI、通道数、默认采样率等字段定义见 AudioDeviceList.py。这些信息会通过ServerDevice.get_info()上报给前端供设备下拉框渲染。采样率校验机制由于不同设备支持的采样率不同服务端在上屏前必须校验采样率。checkSamplingRate()AudioDeviceList.py会以目标采样率尝试打开sd.InputStream/sd.OutputStream成功返回True失败返回False。候选采样率列表定义在 server/const.py[16000, 32000, 44100, 48000, 96000, 192000]。在ServerDevice.start()中ServerDevice.py服务端会先校验当前采样率是否可用若不可用则遍历上述候选列表输出每个设备的可用采样率并等待重试从而避免静默失败。核心配置项ServerDeviceSettingsserver device mode 的全部可调参数集中在 ServerDeviceSettings字段默认值含义enableServerAudio0总开关0offclient device mode1onserver device modeserverAudioStated0服务端音频运行状态0off1onserverInputAudioSampleRate44100输入采样率serverOutputAudioSampleRate44100输出采样率serverMonitorAudioSampleRate44100监听输出采样率serverAudioSampleRate44100统一使用的采样率输入/输出/监听在启动时会被统一到该值serverInputDeviceId-1输入设备 ID-1 表示未启用serverOutputDeviceId-1输出设备 IDserverMonitorDeviceId-1监听设备 ID-1 表示无监听serverReadChunkSize256读取块大小serverInputAudioGain1.0输入增益serverOutputAudioGain1.0输出增益serverMonitorAudioGain1.0监听增益exclusiveModeFalse独占模式WASAPI exclusive其中EditableServerDeviceSettingsServerDevice.py定义了哪些字段可由前端写入。持久化方面VoiceChangerManager.py 会把enableServerAudio、serverAudioSampleRate、serverInputDeviceId、serverOutputDeviceId、serverMonitorDeviceId、serverReadChunkSize及各增益等关键项存入本地设置文件重启后仍可恢复。三种运行布局NoMonitor / WithMonitor当启用 server device mode 且设置了监听设备serverMonitorDeviceId ! -1时服务端会根据输入、输出、监听三者的 Host API 是否一致自动判定采用哪种音频流布局judgeServerDeviceMode()ServerDevice.pyNoMonitorSeparate无监听设备输入流与输出流分开运行runNoMonitorSeparateWithMonitorStandard输入与监听共用一个sd.Stream双工输出单独运行runWithMonitorStandardWithMonitorAllSeparate输入、输出、监听三者各自使用独立的流runWithMonitorAllSeparate。判定规则为三者的 Host API 完全相同 →WithMonitorStandard至少输入与监听相同 →WithMonitorStandard其余情况 →WithMonitorAllSeparate无法判定时抛RuntimeError。之所以如此设计是因为同一 Host API 下的设备可以共享一个全双工流而跨 Host API 时必须拆分为独立流。源码注释也引用了 issue #620 作为该设计的背景。独占模式WASAPI ExclusiveexclusiveMode开启后ServerDevice.py若设备的 Host API 为 WASAPI则为输入/输出/监听分别附加sd.WasapiSettings(exclusiveTrue)以获得更低的系统混音延迟——这正是 server device mode 追求低延迟的进一步手段。在界面上切换设备模式前端设备区域的实现在 client/demo/src/components/demo/components2/102-3_DeviceArea.tsx通过serverSetting.serverSetting.enableServerAudio判断当前模式0显示 client device mode 控件1显示 server device mode 控件见 102-3_DeviceArea.tsxserver device mode 下前端会列出服务端上报的输入/输出设备serverAudioInputDevices/serverAudioOutputDevices并将选择的serverInputDeviceId、serverOutputDeviceId等回写服务端如 102-3_DeviceArea.tsx切换enableServerAudio后服务端ServerDevice.start()会监听设置变化checkSettingChanged()ServerDevice.py在设备 ID、采样率或块大小变化时自动重启音频流。选择建议综合官方教程与源码实现可给出如下决策参考追求低延迟、希望直接掌控音频链路选择 server device mode并确认麦克风/扬声器能被 sounddevice 正确枚举必要时开启exclusiveModeWASAPI进一步压低延迟。依赖 Chrome 的噪声消除等 Web 会议能力、或设备在 server 模式下无法正常使用回退到 client device mode让浏览器代为处理设备兼容性。需要监听Monitor输出在 server device mode 中设置serverMonitorDeviceId服务端会自动在三种流布局间选择合适方案。两种模式在当前版本中并行可用官方教程也明确强调用户应根据各自的优点与缺点结合自己的硬件环境与实际场景区分使用。赞分享人工智能语音模型推理服务深度学习【免费下载链接】voice-changerリアルタイムボイスチェンジャー Realtime Voice Changer项目地址https://gitcode.com/gh_mirrors/vo/voice-changer点击查看免费下载相关推荐如何永久保存微信聊天记录3步实现本地安全备份的完整指南如何永久保存微信聊天记录3步实现本地安全备份的完整指南 你是否担心更换手机或系统升级时丢失宝贵的微信聊天记录那些记录着重要工作沟通、家庭温馨对话和珍贵友谊的人工智能语音模型推理服务深度学习Voice Changer 的 Server Device Mode 监听输出Monitor Output详解v.1.5.3.7 多输出架构与采样率配置实战Voice Changer 的 Server Device Mode 监听输出Monitor Output详解v.1.5.3.7 多输出架构与采样率配置实人工智能语音模型推理服务深度学习CANN Runtime 多设备编程实战多 Device 选择、Stream/Event 行为与跨 Device P2P 数据交互CANN Runtime 多设备编程实战多 Device 选择、Stream/Event 行为与跨 Device P2P 数据交互 本篇技术指南以 CANNCANNAscend人工智能任务调度上一篇XSStrike日志级别控制从详细调试到简洁报告的切换下一篇ivy代码质量标准从风格检查到性能测试的全流程规范创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
