3分钟搞定电脑声音设置完整示例
面试被问音频底层原理答不上来？别慌，今天拆解电脑声音设置完整示例。
很多后端或全栈同学觉得音频设置是前端的事，跟后端八竿子打不着。但真到了面试现场，尤其是涉及实时通信、IoT设备控制或跨平台客户端开发时，面试官一句“系统级音频路由怎么实现？”就能让你露馅。
核心痛点就在这： 你背了一堆网络协议，却说不清OS层的声音管道机制。
这篇文章不讲虚的，直接上干货。我们把“电脑声音设置”这个看似简单的功能，拆解成可面试、可落地、可复用的技术栈。文中包含基于 NPM/PyPI 官方包 的完整示例，让你不仅懂原理，还能直接抄作业。
考点梳理：面试官到底在考什么？
别把“电脑声音设置”想得太简单。在技术语境下，它不是指你去控制面板里调音量，而是指程序如何与操作系统音频子系统交互。
1. 音频I/O基础模型
面试第一关，通常问的是数据流向。声音从麦克风进，经过ADC（模数转换），变成PCM流，经过DSP处理，再经过DAC（数模转换）输出到扬声器。
考点： 采样率（Sample Rate）、位深度（Bit Depth）、声道数（Channels）。
常见坑： 混淆“采样率”和“比特率”。采样率是每秒采集多少次（如44100Hz），比特率是数据大小（如320kbps）。
2. 系统级API差异
这是区分初级和中级工程师的分水岭。
Windows: 核心是 WASAPI (Windows Audio Session API)。它是独占模式和共享模式的基石。
macOS: 核心是 Core Audio。
Linux: 核心是 ALSA (Advanced Linux Sound Architecture) 和 PulseAudio/PIPEWire。
考点： 为什么跨平台音频开发这么难？因为底层API完全不统一，需要封装层（如 PortAudio, FFmpeg）。
3. 设备枚举与路由
如何获取当前可用的输入/输出设备？如何切换默认设备？如何监听设备热插拔？
考点： 设备句柄管理、回调机制、异步I/O。
4. 权限与安全
现代操作系统对音频权限管控越来越严。
macOS: 需要用户显式授权麦克风访问。
Windows: UAC权限级别，管理员模式才能操作某些系统音频流。
考点： 权限申请流程、错误码处理（如“权限被拒绝”）。
标准答法：如何组织你的回答？
面试回答要有结构，建议采用 “背景-原理-实践-优化” 四步法。
第一步：定义场景
“在处理电脑声音设置时，我通常将其分解为三个层面：设备管理、流处理、系统配置。”
第二步：阐述原理
“底层上，Windows使用WASAPI进行低延迟音频捕获和回放。它支持共享模式（多应用混音）和独占模式（绕过系统混音器，低延迟）。在Linux下，ALSA提供底层硬件访问，而PulseAudio/PIPEWire作为用户空间守护进程，负责设备路由和混音。”
第三步：展示实践
“在实际项目中，我使用 NPM/PyPI 官方包 如 python-sounddevice（基于PortAudio）或 Node.js 的 node-wasapi 进行封装。通过回调函数处理音频块（Buffer），避免阻塞主线程。”
第四步：提及优化
“针对延迟问题，我调整了缓冲区大小（Buffer Size）。较小的缓冲区降低延迟但增加CPU占用，较大的缓冲区则相反。通过监测 overrun/underrun 错误率，动态调整缓冲区，平衡了流畅度和实时性。”
加分项： 主动提到“音频时钟漂移”和“重采样”。不同设备的采样率可能不一致，需要进行重采样（Resampling）以匹配，否则会出现音调变化或爆音。
代码实现：完整示例与逐行讲解
光说不练假把式。这里提供一个跨平台的Python完整示例，使用 python-sounddevice（PyPI官方包，底层封装PortAudio）来演示如何获取设备、监听音频流并设置简单参数。
import sounddevice as sd
import numpy as np
import time
def print_available_devices():
步骤1: 枚举系统音频设备
面试考点: 如何区分输入(麦克风)和输出(扬声器)设备
print(Available Audio Devices:)
devices = sd.query_devices()
for i, device in enumerate(devices):
if device['max_input_channels'] 0 or device['max_output_channels'] 0:
print(f[{i}] {device['name']})
print(f Max Input Channels: {device['max_input_channels']})
print(f Max Output Channels: {device['max_output_channels']})
print(f Default Sample Rate: {device['default_samplerate']})
print(- * 40)
def audio_callback(indata, frames, time_info, status):
步骤2: 音频流回调函数
面试考点: 实时音频处理必须在回调中完成，不能阻塞
注意: 此函数运行在独立的音频线程中，严禁执行耗时操作
if status:
print(fStatus: {status})
# 简单处理: 计算当前音量(RMS)
rms = np.sqrt(np.mean(np.square(indata[:, 0])))
# 将RMS转换为分贝 (dB)
if rms 0:
db = 20 * np.log10(rms)
else:
db = -100.0
# 注意: 在高频回调中打印日志会严重影响性能，生产环境建议写入环形缓冲区
# print(fCurrent Volume: {db:.2f} dB)
global current_volume
current_volume = db
def start_audio_monitor(device_index=None, sample_rate=44100, block_size=1024):
步骤3: 启动音频流监听
参数说明:
- device_index: 指定设备索引，None表示默认设备
- sample_rate: 采样率，必须与设备支持的范围匹配
- block_size: 每次回调传输的数据块大小，影响延迟
global current_volume
current_volume = 0.0
if device_index is None:
print(Using default input device.)
else:
print(fUsing device index: {device_index})
# 配置音频流
# channels=1: 单声道，简化处理
# dtype='float32': 32位浮点，便于数学运算
with sd.InputStream(
device=device_index,
samplerate=sample_rate,
channels=1,
dtype='float32',
blocksize=block_size,
callback=audio_callback
):
print(fListening... Press Ctrl+C to stop.)
print(fSample Rate: {sample_rate} Hz)
print(fBlock Size: {block_size} frames)
try:
while True:
time.sleep(1)
# 模拟主线程其他工作，比如UI更新或数据上报
print(f[Main Thread] Current Volume: {current_volume:.2f} dB)
except KeyboardInterrupt:
print(\nStopping audio stream...)
if __name__ == __main__:
# 1. 先查看设备
print_available_devices()
# 2. 启动监听 (假设默认麦克风可用)
# 如果指定设备，请修改 device_index
start_audio_monitor(device_index=None)
代码逐行讲解与面试话术
sd.query_devices():
考点： 设备发现。
话术： “程序启动时，我会调用系统API枚举所有音频设备。这一步是异步安全的，但在某些旧系统上可能较慢，建议放在后台线程执行，避免阻塞UI初始化。”
audio_callback 函数:
考点： 实时性约束。
话术： “音频回调是实时系统中最关键的部分。这里我做了两件事：一是检查 status，处理缓冲区溢出（overrun）或下溢（underrun）；二是计算RMS音量。特别注意，这里没有执行 print 到控制台，因为在生产环境中，I/O操作会导致回调超时，进而产生爆音。我会将数据放入内存队列，由另一个线程负责日志输出。”
sd.InputStream 上下文管理器:
考点： 资源管理与生命周期。
话术： “使用上下文管理器确保流在退出时正确关闭，释放系统音频设备锁。如果多个进程试图独占同一设备，后启动的进程会失败，因此我们需要处理 PortAudioError 异常，给用户友好的提示。”
block_size 参数:
考点： 延迟与稳定性的权衡。
话术： “block_size 设为1024帧。在44100Hz采样率下，每帧约23ms。如果面试官问‘为什么不是更小的值？’，我会回答：更小的块（如128帧）能降低延迟，但会增加CPU调度开销，且在低端设备上容易因系统抖动导致underrun。1024是一个在大多数PC上平衡了延迟和稳定性的经验值。”
追问与延伸：如何拉开差距？
当基础答完后，面试官通常会追问细节。准备以下几个“杀手锏”问题。
追问1：如何处理设备热插拔？
错误回答： “重启程序。”
高分回答： “操作系统提供了设备变化回调机制。在Windows WASAPI中，可以使用 IAudioClient::GetMixFormat 配合设备通知接口。在Python中，python-sounddevice 支持 sd.query_devices 轮询，但更专业的做法是使用底层库的回调API。检测到设备移除时，程序应平滑停止音频流，并提示用户重新选择设备，而不是直接崩溃。”
追问2：采样率不匹配怎么办？
错误回答： “忽略它。”
高分回答： “如果麦克风输出48kHz，而系统播放是44.1kHz，直接播放会导致音调错误。必须引入重采样器（Resampler）。可以使用 scipy.signal.resample 或 soxr 库进行线性插值或更高质量的Sinc插值。重采样计算量大，建议在DSP线程中完成，避免阻塞采集线程。”
追问3：如何降低音频延迟？
错误回答： “调小缓冲区。”
高分回答： “降低延迟是一个系统工程。
硬件层： 选择低延迟音频接口。
驱动层： 使用WASAPI独占模式或Core Audio实时模式，绕过系统混音器。
软件层： 减小 block_size，使用环形缓冲区（Ring Buffer）解耦采集和处理。
调度层： 提高音频线程优先级（Real-time priority）。在Linux下，可能需要配置 realtime-priority 权限。
注意：过低的延迟会导致‘爆音’（Glitch），因为CPU来不及处理数据。我们需要找到‘最小稳定延迟’。”
追问4：权限问题如何解决？
错误回答： “让用户自己开权限。”
高分回答： “在macOS上，首次调用麦克风API会触发系统弹窗。程序需要捕获 PermissionDenied 错误，并引导用户去‘系统偏好设置-隐私-麦克风’中开启权限。在Windows上，如果程序以管理员身份运行，可能无法访问普通用户的音频流，建议以普通用户身份运行，除非必须访问系统级音频。”
记忆口诀：面试速记卡片
为了方便记忆，这里总结一个口诀：“查设回阻权”。
查（Query）： 枚举设备，区分输入输出，检查采样率支持范围。
设（Setup）： 配置音频流参数（采样率、通道、块大小），选择共享或独占模式。
回（Callback）： 回调函数中只做轻量级计算，严禁I/O和阻塞，数据入队。
阻（Buffer）： 理解缓冲区机制，Overrun/Underrun处理，动态调整块大小平衡延迟与稳定。
权（Permission）： 处理OS权限申请，设备热插拔监听，异常捕获与用户引导。
岗位日常职责边界与报考要求
在面试中，除了技术细节，还要了解这个领域的职责边界。
前端/客户端工程师： 重点关注浏览器API（Web Audio API）或移动端SDK封装。职责是调用高层API，处理UI交互，处理权限弹窗。通常不需要深入OS底层驱动。
后端/系统工程师： 重点关注服务器端的音频处理（如TTS、ASR、音频转码）。职责是使用FFmpeg等库进行批量处理，不涉及实时低延迟交互。
嵌入式/IoT工程师： 重点关注ALSA/FreeRTOS音频任务。职责是配置硬件寄存器，优化中断响应，处理DMA传输。
报考学历与工作年限要求：
初级岗位（1-3年）： 本科及以上学历，计算机相关专业。要求熟悉一种主流语言（Python/Java/JS），理解基本的I/O模型。能使用现有库实现基本功能。
中级岗位（3-5年）： 要求有跨平台音频项目经验。能阅读PortAudio/WASAPI源码，能解决延迟、爆音、设备冲突等复杂问题。熟悉Linux音频栈（ALSA/PulseAudio）是加分项。
高级岗位（5年以上）： 要求有音频算法优化经验（DSP、重采样、回声消除）。能设计低延迟音频架构，指导团队解决底层驱动问题。通常要求硕士及以上学历，或有丰富的嵌入式/系统编程背景。
避坑指南：
不要死记API： 面试官更看重你对“流”、“缓冲区”、“线程模型”的理解。
不要忽视异常： 音频设备故障是常态，代码必须有完善的错误处理和日志。
不要忽略性能： 实时音频对CPU占用敏感，代码要高效，避免不必要的内存分配。
结尾互动
音频开发是一个“看不见摸不着”的领域，很多Bug只能通过耳朵听出来。
你公司项目里是怎么处理音频设备热插拔的？是轮询还是回调？欢迎在评论区分享你的实战经验，或者吐槽你踩过的最离谱的音频Bug。
如果这篇文章对你有启发，记得点赞收藏，下次面试前复习一下“查设回阻权”。
注：本文代码基于 Python 3.8+ 和 python-sounddevice 0.4.5+ 测试。不同操作系统下，设备名称和索引可能不同，请根据 print_available_devices() 的输出调整。 
长河君 · 2026/9/21 21:19:27 · 阅读 1.2k 3分钟搞定电脑声音设置完整示例
3分钟搞定电脑声音设置完整示例
面试被问音频底层原理答不上来？别慌，今天拆解电脑声音设置完整示例。
很多后端或全栈同学觉得音频设置是前端的事，跟后端八竿子打不着。但真到了面试现场，尤其是涉及实时通信、IoT设备控制或跨平台客户端开发时，面试官一句“系统级音频路由怎么实现？”就能让你露馅。
核心痛点就在这： 你背了一堆网络协议，却说不清OS层的声音管道机制。
这篇文章不讲虚的，直接上干货。我们把“电脑声音设置”这个看似简单的功能，拆解成可面试、可落地、可复用的技术栈。文中包含基于 NPM/PyPI 官方包 的完整示例，让你不仅懂原理，还能直接抄作业。
考点梳理：面试官到底在考什么？
别把“电脑声音设置”想得太简单。在技术语境下，它不是指你去控制面板里调音量，而是指程序如何与操作系统音频子系统交互。
1. 音频I/O基础模型
面试第一关，通常问的是数据流向。声音从麦克风进，经过ADC（模数转换），变成PCM流，经过DSP处理，再经过DAC（数模转换）输出到扬声器。
考点： 采样率（Sample Rate）、位深度（Bit Depth）、声道数（Channels）。
常见坑： 混淆“采样率”和“比特率”。采样率是每秒采集多少次（如44100Hz），比特率是数据大小（如320kbps）。
2. 系统级API差异
这是区分初级和中级工程师的分水岭。
Windows: 核心是 WASAPI (Windows Audio Session API)。它是独占模式和共享模式的基石。
macOS: 核心是 Core Audio。
Linux: 核心是 ALSA (Advanced Linux Sound Architecture) 和 PulseAudio/PIPEWire。
考点： 为什么跨平台音频开发这么难？因为底层API完全不统一，需要封装层（如 PortAudio, FFmpeg）。
3. 设备枚举与路由
如何获取当前可用的输入/输出设备？如何切换默认设备？如何监听设备热插拔？
考点： 设备句柄管理、回调机制、异步I/O。
4. 权限与安全
现代操作系统对音频权限管控越来越严。
macOS: 需要用户显式授权麦克风访问。
Windows: UAC权限级别，管理员模式才能操作某些系统音频流。
考点： 权限申请流程、错误码处理（如“权限被拒绝”）。
标准答法：如何组织你的回答？
面试回答要有结构，建议采用 “背景-原理-实践-优化” 四步法。
第一步：定义场景
“在处理电脑声音设置时，我通常将其分解为三个层面：设备管理、流处理、系统配置。”
第二步：阐述原理
“底层上，Windows使用WASAPI进行低延迟音频捕获和回放。它支持共享模式（多应用混音）和独占模式（绕过系统混音器，低延迟）。在Linux下，ALSA提供底层硬件访问，而PulseAudio/PIPEWire作为用户空间守护进程，负责设备路由和混音。”
第三步：展示实践
“在实际项目中，我使用 NPM/PyPI 官方包 如 python-sounddevice（基于PortAudio）或 Node.js 的 node-wasapi 进行封装。通过回调函数处理音频块（Buffer），避免阻塞主线程。”
第四步：提及优化
“针对延迟问题，我调整了缓冲区大小（Buffer Size）。较小的缓冲区降低延迟但增加CPU占用，较大的缓冲区则相反。通过监测 overrun/underrun 错误率，动态调整缓冲区，平衡了流畅度和实时性。”
加分项： 主动提到“音频时钟漂移”和“重采样”。不同设备的采样率可能不一致，需要进行重采样（Resampling）以匹配，否则会出现音调变化或爆音。
代码实现：完整示例与逐行讲解
光说不练假把式。这里提供一个跨平台的Python完整示例，使用 python-sounddevice（PyPI官方包，底层封装PortAudio）来演示如何获取设备、监听音频流并设置简单参数。
import sounddevice as sd
import numpy as np
import time
def print_available_devices():
步骤1: 枚举系统音频设备
面试考点: 如何区分输入(麦克风)和输出(扬声器)设备
print(Available Audio Devices:)
devices = sd.query_devices()
for i, device in enumerate(devices):
if device['max_input_channels'] 0 or device['max_output_channels'] 0:
print(f[{i}] {device['name']})
print(f Max Input Channels: {device['max_input_channels']})
print(f Max Output Channels: {device['max_output_channels']})
print(f Default Sample Rate: {device['default_samplerate']})
print(- * 40)
def audio_callback(indata, frames, time_info, status):
步骤2: 音频流回调函数
面试考点: 实时音频处理必须在回调中完成，不能阻塞
注意: 此函数运行在独立的音频线程中，严禁执行耗时操作
if status:
print(fStatus: {status})
# 简单处理: 计算当前音量(RMS)
rms = np.sqrt(np.mean(np.square(indata[:, 0])))
# 将RMS转换为分贝 (dB)
if rms 0:
db = 20 * np.log10(rms)
else:
db = -100.0
# 注意: 在高频回调中打印日志会严重影响性能，生产环境建议写入环形缓冲区
# print(fCurrent Volume: {db:.2f} dB)
global current_volume
current_volume = db
def start_audio_monitor(device_index=None, sample_rate=44100, block_size=1024):
步骤3: 启动音频流监听
参数说明:
- device_index: 指定设备索引，None表示默认设备
- sample_rate: 采样率，必须与设备支持的范围匹配
- block_size: 每次回调传输的数据块大小，影响延迟
global current_volume
current_volume = 0.0
if device_index is None:
print(Using default input device.)
else:
print(fUsing device index: {device_index})
# 配置音频流
# channels=1: 单声道，简化处理
# dtype='float32': 32位浮点，便于数学运算
with sd.InputStream(
device=device_index,
samplerate=sample_rate,
channels=1,
dtype='float32',
blocksize=block_size,
callback=audio_callback
):
print(fListening... Press Ctrl+C to stop.)
print(fSample Rate: {sample_rate} Hz)
print(fBlock Size: {block_size} frames)
try:
while True:
time.sleep(1)
# 模拟主线程其他工作，比如UI更新或数据上报
print(f[Main Thread] Current Volume: {current_volume:.2f} dB)
except KeyboardInterrupt:
print(\nStopping audio stream...)
if __name__ == __main__:
# 1. 先查看设备
print_available_devices()
# 2. 启动监听 (假设默认麦克风可用)
# 如果指定设备，请修改 device_index
start_audio_monitor(device_index=None)
代码逐行讲解与面试话术
sd.query_devices():
考点： 设备发现。
话术： “程序启动时，我会调用系统API枚举所有音频设备。这一步是异步安全的，但在某些旧系统上可能较慢，建议放在后台线程执行，避免阻塞UI初始化。”
audio_callback 函数:
考点： 实时性约束。
话术： “音频回调是实时系统中最关键的部分。这里我做了两件事：一是检查 status，处理缓冲区溢出（overrun）或下溢（underrun）；二是计算RMS音量。特别注意，这里没有执行 print 到控制台，因为在生产环境中，I/O操作会导致回调超时，进而产生爆音。我会将数据放入内存队列，由另一个线程负责日志输出。”
sd.InputStream 上下文管理器:
考点： 资源管理与生命周期。
话术： “使用上下文管理器确保流在退出时正确关闭，释放系统音频设备锁。如果多个进程试图独占同一设备，后启动的进程会失败，因此我们需要处理 PortAudioError 异常，给用户友好的提示。”
block_size 参数:
考点： 延迟与稳定性的权衡。
话术： “block_size 设为1024帧。在44100Hz采样率下，每帧约23ms。如果面试官问‘为什么不是更小的值？’，我会回答：更小的块（如128帧）能降低延迟，但会增加CPU调度开销，且在低端设备上容易因系统抖动导致underrun。1024是一个在大多数PC上平衡了延迟和稳定性的经验值。”
追问与延伸：如何拉开差距？
当基础答完后，面试官通常会追问细节。准备以下几个“杀手锏”问题。
追问1：如何处理设备热插拔？
错误回答： “重启程序。”
高分回答： “操作系统提供了设备变化回调机制。在Windows WASAPI中，可以使用 IAudioClient::GetMixFormat 配合设备通知接口。在Python中，python-sounddevice 支持 sd.query_devices 轮询，但更专业的做法是使用底层库的回调API。检测到设备移除时，程序应平滑停止音频流，并提示用户重新选择设备，而不是直接崩溃。”
追问2：采样率不匹配怎么办？
错误回答： “忽略它。”
高分回答： “如果麦克风输出48kHz，而系统播放是44.1kHz，直接播放会导致音调错误。必须引入重采样器（Resampler）。可以使用 scipy.signal.resample 或 soxr 库进行线性插值或更高质量的Sinc插值。重采样计算量大，建议在DSP线程中完成，避免阻塞采集线程。”
追问3：如何降低音频延迟？
错误回答： “调小缓冲区。”
高分回答： “降低延迟是一个系统工程。
硬件层： 选择低延迟音频接口。
驱动层： 使用WASAPI独占模式或Core Audio实时模式，绕过系统混音器。
软件层： 减小 block_size，使用环形缓冲区（Ring Buffer）解耦采集和处理。
调度层： 提高音频线程优先级（Real-time priority）。在Linux下，可能需要配置 realtime-priority 权限。
注意：过低的延迟会导致‘爆音’（Glitch），因为CPU来不及处理数据。我们需要找到‘最小稳定延迟’。”
追问4：权限问题如何解决？
错误回答： “让用户自己开权限。”
高分回答： “在macOS上，首次调用麦克风API会触发系统弹窗。程序需要捕获 PermissionDenied 错误，并引导用户去‘系统偏好设置-隐私-麦克风’中开启权限。在Windows上，如果程序以管理员身份运行，可能无法访问普通用户的音频流，建议以普通用户身份运行，除非必须访问系统级音频。”
记忆口诀：面试速记卡片
为了方便记忆，这里总结一个口诀：“查设回阻权”。
查（Query）： 枚举设备，区分输入输出，检查采样率支持范围。
设（Setup）： 配置音频流参数（采样率、通道、块大小），选择共享或独占模式。
回（Callback）： 回调函数中只做轻量级计算，严禁I/O和阻塞，数据入队。
阻（Buffer）： 理解缓冲区机制，Overrun/Underrun处理，动态调整块大小平衡延迟与稳定。
权（Permission）： 处理OS权限申请，设备热插拔监听，异常捕获与用户引导。
岗位日常职责边界与报考要求
在面试中，除了技术细节，还要了解这个领域的职责边界。
前端/客户端工程师： 重点关注浏览器API（Web Audio API）或移动端SDK封装。职责是调用高层API，处理UI交互，处理权限弹窗。通常不需要深入OS底层驱动。
后端/系统工程师： 重点关注服务器端的音频处理（如TTS、ASR、音频转码）。职责是使用FFmpeg等库进行批量处理，不涉及实时低延迟交互。
嵌入式/IoT工程师： 重点关注ALSA/FreeRTOS音频任务。职责是配置硬件寄存器，优化中断响应，处理DMA传输。
报考学历与工作年限要求：
初级岗位（1-3年）： 本科及以上学历，计算机相关专业。要求熟悉一种主流语言（Python/Java/JS），理解基本的I/O模型。能使用现有库实现基本功能。
中级岗位（3-5年）： 要求有跨平台音频项目经验。能阅读PortAudio/WASAPI源码，能解决延迟、爆音、设备冲突等复杂问题。熟悉Linux音频栈（ALSA/PulseAudio）是加分项。
高级岗位（5年以上）： 要求有音频算法优化经验（DSP、重采样、回声消除）。能设计低延迟音频架构，指导团队解决底层驱动问题。通常要求硕士及以上学历，或有丰富的嵌入式/系统编程背景。
避坑指南：
不要死记API： 面试官更看重你对“流”、“缓冲区”、“线程模型”的理解。
不要忽视异常： 音频设备故障是常态，代码必须有完善的错误处理和日志。
不要忽略性能： 实时音频对CPU占用敏感，代码要高效，避免不必要的内存分配。
结尾互动
音频开发是一个“看不见摸不着”的领域，很多Bug只能通过耳朵听出来。
你公司项目里是怎么处理音频设备热插拔的？是轮询还是回调？欢迎在评论区分享你的实战经验，或者吐槽你踩过的最离谱的音频Bug。
如果这篇文章对你有启发，记得点赞收藏，下次面试前复习一下“查设回阻权”。
注：本文代码基于 Python 3.8+ 和 python-sounddevice 0.4.5+ 测试。不同操作系统下，设备名称和索引可能不同，请根据 print_available_devices() 的输出调整。