Go malgo 播放设备与捕获设备怎样区分

我第一次用 Go malgo 做一个“既能播放提示音，又能录入麦克风”的小工具时，最容易混淆的不是采样率，而是设备方向。Playback、Capture、Duplex 和 Loopback 不是设备名称，它们是筛选和初始化时使用的设备类型。要区分播放设备与捕获设备，先按方向调用 Context.Devices，再让 DeviceConfig.DeviceType 使用同一个语义。

官方地址：https://pkg.go.dev/github.com/gen2brain/malgo

只需要输出声音时选 Playback，只需要读取麦克风时选 Capture；同时输入和输出才考虑 Duplex。Loopback 是回采系统播放内容的特殊方向，不应当当作普通麦克风设备。

先把四种 DeviceType 当成筛选边界

malgo 的 DeviceType 常量有四个：Playback 表示播放端，Capture 表示采集端，Duplex 表示同一个设备实例同时承担播放和采集，Loopback 用于获取系统播放链路中的回采数据。这个区分发生在设备发现和设备初始化之前，不能等创建出 Device 后再靠名字猜方向。

枚举时分别读取播放和捕获列表

Context.Devices(kind) 返回指定类型下活动设备的基本信息。实际项目里我会先分别读取两个列表，把 DeviceInfo.Name() 当作给用户看的选择线索，把 DeviceInfo.String() 或设备 ID 保存到选择状态中。不要因为某个名称包含“Speaker”就断定它一定适合当前配置，最终方向仍由 DeviceType 决定。

package main

import (
    "fmt"
    "github.com/gen2brain/malgo"
)

func listDevices(ctx malgo.Context, kind malgo.DeviceType) error {
    // 只枚举当前方向的活动设备，避免把播放和录音候选混在一起。
    devices, err := ctx.Devices(kind)
    if err != nil {
        return fmt.Errorf("枚举设备失败: %w", err)
    }
    for _, info := range devices {
        // 名称用于展示；真正初始化时仍要保留 kind 这一方向信息。
        fmt.Println(info.Name())
    }
    return nil
}

func showCandidates(ctx malgo.Context) error {
    if err := listDevices(ctx, malgo.Playback); err != nil {
        return err
    }
    // 捕获列表单独读取，便于 UI 或配置文件保存两组候选。
    return listDevices(ctx, malgo.Capture)
}

如果 Devices(malgo.Playback) 有结果而 Devices(malgo.Capture) 为空，问题首先应从后端权限、系统输入设备状态和当前平台能力查起，而不是把播放设备强行改成捕获设备。

初始化配置必须跟目标方向一致

选好候选后，使用 DefaultDeviceConfig(deviceType) 生成基础配置，再修改采样率、周期或回调。配置里的 DeviceType 是契约的一部分：播放任务传 Playback，录音任务传 Capture，全双工任务传 Duplex。只改设备 ID 而不改类型，常见结果是回调数据方向与业务假设不一致。

我会把“任务目标”和“设备选择”分成两个字段保存：目标决定类型，用户选择决定 ID。这样切换默认扬声器时不必重新解释业务方向，也能在设备断开后重新枚举同方向候选。

Duplex 和 Loopback 不要按普通单向设备处理

Duplex 适合输入输出需要同时存在的场景，例如通话回声处理；它不是“播放列表和捕获列表各取一个”的快捷写法，而是让一个设备配置同时描述两个方向。创建后应分别关注 PlaybackChannels() 与 CaptureChannels()，不要只检查其中一个。

Loopback 的目标是读取播放链路中的声音，是否可用还受平台后端影响。它和麦克风捕获的业务含义不同：前者分析系统输出，后者读取外部输入。跨平台程序应把 Loopback 作为能力选项，在目标平台不提供时给出降级提示。

最后按设备再上下文的顺序收尾

malgo 文档说明，仍有设备活动时直接 Context.Uninit() 会产生未定义结果。因此我的收尾顺序是先停止设备，再调用设备的 Uninit()，最后释放由 InitContext 创建的上下文。这个顺序和设备方向无关，却能避免“列表已经切换，旧设备仍占用后端”的隐性问题。

排查时可以记录四项：请求的 DeviceType、选中的设备 ID、实际的播放/捕获通道数，以及 Start 或 Stop 的错误。这样能快速判断是枚举阶段选错方向、初始化配置不匹配，还是平台后端本身不支持。

相关问题

只录麦克风时可以使用 Duplex 吗？

可以创建，但没有必要。单向录音优先使用 Capture，配置更容易理解，排错时也不会把无关的播放能力带进来。

设备名称能不能决定它是播放还是捕获？

不能。名称只是展示信息，方向应由枚举时传入的 DeviceType 和初始化配置共同决定。

为什么 Loopback 列表在一台机器上为空？

Loopback 依赖平台和后端支持。先确认当前后端、系统权限与设备能力，再决定是否提供麦克风捕获或文件输入等降级路径。