之前折腾了远程音频，差不多就是把各个机子的音频转发到另一个机子上，然后在那上面插耳机。好处主要是换机器不用换耳机，全都是一个出口。
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=96000set-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 设备，或许应该从这方面考虑……