远程音频

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

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 设备，或许应该从这方面考虑……

tmux 和剪贴板

tmux 支持鼠标，甚至支持选一段东西之后自动发给剪贴板。这个功能很好用，比如在想从终端贴一段文字到浏览器的时候之类……

然而这个功能有时候需要一些配置。折腾一波之后，发现主要是这么几个部分：

首先 tmux 需要打开鼠标支持，并且让它在复制完之后去设置剪贴板：

set -g mouse on
set -g set-clipboard on

然而这并没完。所谓“设置剪贴板”，其实就是发一段东西给外面的终端模拟器（tmux 归根结底只是发各种东西给终端模拟器而已……），说“设置剪贴板为XXX”。这段东西就是OSC 52。OSC就是“operating system command”，就是某种终端控制序列，用来和系统交互的…… OSC 52 就是里面的命令52，功能是设置剪贴板。

然而 tmux 其实依赖某些信息来告诉他“外面这个终端模拟器支持OSC 52”。这个就是 terminfo 里面的 Ms 能力（属性？）。这个告诉了 tmux，要设置剪贴板应该发什么格式的东西给终端模拟器。

然而我现在用的 term（st-256color）里面貌似并没有这个…… 结果就是就算开了上面这俩，tmux 也不干活。

正确的修正方法当然是把那个属性加进 terminfo，但是这个挺麻烦的，而且每个系统都要加…… 理想状况下我可以只用 tmux.conf 解决问题。

解决方法当然是有的：直接在 tmux.conf 里面修改 terminfo 给的结果…… 所以可以直接告诉 tmux，对某些 terminal（我这里是st*），设置剪贴板就发这个：

set -g terminal-overrides[2] 'st*:XT:Ms=\E]52;%p1%s;%p2%s\007'

我其实还添加了 Tc，所以怎么样都认为支持24位色…… 不过这就是另一个事情了。

搞了这俩之后，tmux 就会发送 OSC 52 了。

最后还有终端模拟器收到这个之后需要设置剪贴板。我现在用的 suckless terminal 是支持的（虽然默认 buffer 大小比较小，所以长一点的文字会被截断，不知道修了没……）。很多别的也是支持的……

这么搞剪贴板支持有如下好处：

1. 远程也能用

ssh 过去之后，选一段东西，也能够很好的复制进本地的剪贴板里面，因为一路传回来了。如果是在 tmux 里面用一个脚本处理鼠标事件之类可能就不行。

2. 分栏也能用

如果用终端模拟器自己的复制功能，那 tmux 分栏的时候就会复制一堆啥分栏符之类的进去。用 tmux 自己的鼠标支持就没这个问题。

3. 简单

只要随便搞几行 config 就完了，不像某些剪贴板支持搞法那么麻烦，又是 binding 又是脚本的……

WiFi 与多播

最近折腾了一波 WiFi……

起因是老的 Netgear R6250 路由的无线好像有点问题。一开始是2.4G有问题，于是我拿出了一个 TP-Link 的小路由来对付2.4G。其实我家普通设备也不用2.4G，也就是那些破智能家居的东西，啥灯泡开关之类，还有啥打印机啦 Kindle啦，这些破烂没法用5G。症状是这些设备时不时就掉线，看看路由的设备列表也会发现大多数2.4G设备都消失了。ping 也不通，出问题的时候尝试手机连2.4G也连不上。

后来我刷了一波 dd-wrt（OpenWrt 没有 5G 支持），结果更糟糕了，有时候直接断网…… 虽然估计是dd-wrt的问题，但是也懒得再刷回去了，反正也有问题。

于是想想这个路由也用了5年了，干脆买个新的。毕竟快要 WiFi 6 (802.11 ax) 了嘛，要买就买支持AX的。等了一段时间的折扣，搞来一个 Netgear AX5200。

买来之后用了没几天，发现2.4G问题依旧…… 症状也差不多，反正就是设备会掉。根据经验么，我就开始折腾路由的各个设置，例如看看哪个频道空啦，改改无线信号频率宽度啦，改改各种WiFi设置啦…… 结果改完居然5G都出问题了，时不时会卡上个半分钟一分钟的，卡完之后ping能收到一堆延时了最多半分钟的包。于是只好恢复出厂设置，然后5G好歹恢复了，所以真的是改设置改出问题了……

所以回头看2.4G相关设置，实在是没啥搞头…… 频道么，公寓楼里每个频道都一堆信号，干扰总是免不了的。然而就算这样，应该也不至于就没法用……

没办法只能拉出来Wireshark抓包，看看有啥希望没有。在2.4G有问题的时候，抓包发现路由偶尔还是能吐出来几个包的，多数都是多播……

于是这个时候我意识到这个可能就是问题：2.4G应该没有设备要听这个多播啊……

说到这个多播吧，其实是远程音频的副产品。因为多个设备都需要播放音频，而我又不想把耳机来回拔插，于是在各个系统都搞了远程音频，各个系统都把音频发到一个机子上。Linux/BSD用的是PulseAudio rtp send/recv，而Windows用的Scream。

这俩底下其实貌似都是RTP，以及都是用的多播。多播这个东西有线网是挺合理的，无线网就比较堪忧了。有些路由器甚至有自动把多播转成单播的功能。一般来说普通用户也没这个需求，所以 Netgear 没在普通路由器做这个也很合理……

虽然吧，还是有些奇怪的。多播应该是要主动申请加入（通过IGMP）的，而那些2.4G的设备显然不会去加入。既然这样，那路由不该把这些多播包发给它们啊……

为了证实是多播的问题，我观察了一下ping的延时和远程音频的关系。结果发现，只要一开始播放音乐，延时就涨到几百，只要一停，过一会就掉回几十……

既然怀疑就是多播的问题，那干掉多播就完了。我把远程音频都改成了单播的，幸好这俩都可以改。改完之后到现在已经三天了，目前看来还没啥问题……

搞完之后回头想想，说不定本来的路由就没问题呢？……

关于在线音乐

某些在线音乐服务真是不行啊……
Amazon Music：音乐库特别小，很多歌找不到……
Youtube Music：这货感觉就没有音质的概念……

今天搜了个很常见的歌，Amazon Music干脆没有，Youtube Music 搜索结果第一位是个不知道谁传上去的视频，音质明显不行，感觉只有64K或者128K…… 这种东西你拿出来还不如说你没有呢…… 随便搜了个320K MP3的，音质天差地别啊……

反正这俩都不能用……