远程音频

之前折腾了远程音频,差不多就是把各个机子的音频转发到另一个机子上,然后在那上面插耳机。好处主要是换机器不用换耳机,全都是一个出口。

Windows 的发送靠 Scream (https://github.com/duncanthrax/scream),可以把音频发送到网上的接收端。Windows 这边是个驱动,也有各种客户端可以收。默认是多播,注册表改改就能单播了……

Linux 靠的是 Pulseaudio 的 rtp send/recv。其实挺简单的,就是弄个 rtp sink 作为默认音频 sink,然后把这个 sink 的收到的东西用 rtp-send 发出去:

load-module module-null-sink sink_name=rtp
load-module module-rtp-send source=rtp.monitor destination_ip=<receiver IP> rate=96000

set-default-sink rtp

接收端么弄个 rtp-recv,就行了:

load-module module-rtp-recv sap_address=<receiver IP>

就像我之前说的,默认这货会用多播,然后导致一些 WiFi 问题…… 所以要指定 IP 才行。

FreeBSD 嘛比较麻烦点。首先,支持 Pulseaudio 的程序可以按 Linux 一样处理。然而,有些程序就认基础的 oss,打开 /dev/dsp 就用……

对这种东西当然可以用padsp,不过这货好像有点bug,不太行。我找了个结合 virtual_oss 和 Pulseaudio 的方法。

首先用 virtual_oss 模拟一个 /dev/dsp 出来,把收到的东西从另一个 loopback dsp 发出去:

virtual_oss_enable="YES"
virtual_oss_dsp="-T /dev/sndstat -S -c 2 -r 48000 -b 24 -s 8ms -l dsploop -f /dev/null -d dsp -t dsp.ctl"

然后让 Pulseaudio 把这个 loopback dsp 收到的东西发给 rtp:

load-module module-oss device=/dev/dsploop sink_name=dsploop_sink source_name=dsploop_source
load-module module-loopback latency_msec=1 source=dsploop_source sink=rtp

然后就搞完了。延迟还能接受,应该还是略高。

说到延迟,Pulseaudio 的延迟好像总是不小,Scream 就几乎没有。估计和 buffer 多大有关系吧……

最后,Android 设备目前还没啥想法…… 考虑到 Android 支持 USB Audio 设备,或许应该从这方面考虑……

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.