远程音频

之前折腾了远程音频,差不多就是把各个机子的音频转发到另一个机子上,然后在那上面插耳机。好处主要是换机器不用换耳机,全都是一个出口。 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=rtpload-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 的方法。 …

Continue reading ‘远程音频’ »

Pixel C 也鼓起来了

前两天突然发现,我平时插着电当时钟的 Pixel C 也鼓起来了。具体来说,屏幕隆起来,和背壳中间有了条缝: 看见这个,作为一个已经鼓了两个平板一个手表的人,我迅速做出判断:又一个平板的电池鼓起来了…… 我想能不能拆掉电池,就插电继续当时钟。然而这货并不好拆,iFixit 做过一个拆解,屏幕是用一圈胶黏在背壳(铝合金)上面的,硬掰的话,很容易掰坏屏幕(毕竟是一块玻璃)。 听说点吹风加热能好弄一点,于是我也试了一把,感觉有那么点效果。在拿一个塑料片子折腾了半天之后,终于把鼓得厉害的两条边分离了: 然后继续拿塑料片划拉。屏幕和背壳之间那个胶可以慢慢蹭掉,每次划开一点。因为电池鼓着,所以划开之后基本就不会再合起来了。 蹭了很久之后,终于完全蹭开来了。分开之后是这个样子(有俩排线): 断电之后,下一个问题就是咋拆掉电池。iFixit 的拆解都没拆电池,因为实在是粘得太牢。我拿了几张过期银行卡之类的在底下死命往里划拉,慢慢的还是把电池和背壳分离了开来。最后就是这个样子: 然后插电,发现大功率充电器能够启动到fastboot,然而不能进系统;小功率的根本不亮。简单来说,没电池看来不太行…… 去网上看了眼,很少有卖这个电池的,大概三十一份,倒是不算贵。然而这货我基本也是吃灰状态,买来也没啥用。另外,根据之前 Nexus 7 2013的经验,买来的电池很快也会鼓…… 于是先暂时放着了。不知道这个显示面板能不能插到别的啥上面用用,比如这个 Pine64 之类的。 总的来说,我已经鼓了3个平板了:Pixel 7 2013,Surface Pro 4,以及 Pixel C。Surface Pro 4 微软给换了一个,到目前为止还没鼓起来。Pixel 7 2013 我倒是换过电池,然而没多久又鼓了。 这个 Pixel C 是 2016 年初买的,到现在差不多是4年。看了眼之前的blog,Nexus 7 是2017年买的,差不多也是4年。看来这种平板电池寿命就是4年,如果一直插在上面的话。Surface Pro 4 是18年鼓起来的,16年8月买的,看来是特别不行…… 可能和这货很容易温度特别高(这是个i7……)有关系…… 网上说鼓起来基本是过充,虽然这些电池应该都有智能保护电路,估计一直插着就有这个问题。这样来看,不用的平板一直插着并不是啥好主意。这样的话,需要一直插着电的东西,还是选没电池的比较好。 看了眼现在当媒体播放器的 Pixel Slate,感觉也很危险,看来要考虑换一个设备当播放器了…… 其实我还有个 NVIDIA Shield,然而这货那个 Android TV 并不好用,不如 …

Continue reading ‘Pixel C 也鼓起来了’ »

多设备蓝牙键盘

这东西倒也没啥新鲜的,罗技基本上现在每个都有这个功能。然而家里键盘并不想换,反正还有个扔着没用的 Pine64,就考虑结合一下变成多设备蓝牙键盘…… 输入嘛就靠libinput。这年头拿个输入还是很方便的,拿python的wrapper随便折腾折腾就有了。 蓝牙比较麻烦。本身蓝牙就比较复杂,要先搞 SDP 记录然后再接收连接。参考了网上直接模拟蓝牙键盘的代码,改改 HID 描述符加上鼠标,加上接收多个连接的功能,搞个快捷键切换设备,也就差不多了。 蓝牙键盘鼠标和 USB 的那套差不多,就是 HID 套个壳。这个倒是比较简单,之前也研究过 HID 描述符和 HID 报告的格式,随便折腾一下就能发送报告了。然而被 Python 3 的 bytes/str 坑了一波,最后发现 0xa1 发送成了 0xc2 0xa1 才注意到这个问题…… 目前倒是折腾到能用,然而蓝牙那块还是有一些诡异的问题。比如说,Android 和 Linux 经常连不上来,看上去 bluez 这边发送的回复是说 Connection pending, Authentication pending,过一会就 fail 了,然而有时候又能跑,还需要更多研究…… 至于为啥不直接用 synergy 或者远程跑个服务器然后发数据嘛…… 因为毕竟蓝牙比较通用,远程不需要啥设置,以及折腾折腾比较好玩…… 说起来折腾这货还发现了奇妙的bug。只要(不)恰当地设置 SDP 记录,Windows一连上就会蓝屏…… KERNEL_SECRUITY_CHECK_EXCEPTION来着。 https://github.com/HenryHu/bthub/tree/master/src

关于一堆可疑的SNMP包

很久以前,我系的CRF(管理计算机资源的)来找过我,说我机子被黑了。我观察之后没啥症状,就问他们为啥那么说。 他们拿出来一个单子,说你机子往外发可疑的包,只有被黑了才发这种包。 我看了一眼,貌似我的机子在广播SNMP包。我觉得这事情也不是那么奇怪,毕竟一堆程序依赖snmp库,但是他们觉得有问题。 于是我在防火墙加了个规则,说如果有这种包就记录一下并且扔掉。其他还干了很多事情,例如换私钥之类,总之很麻烦。之后,他们就不来找我了…… 系统里的确偶尔会记录下这种包的发送记录。那时候尝试看了一眼,没看出为啥,也就没有管。 过了很久之后,一天我看着这些记录,觉得很烦躁,想着干脆研究清楚为啥会发这些破包。 首先,那些个记录里记录了发包者的UID。在我的机子上,记录的UID是colord的UID。 colord是啥呢?可以参见http://www.freedesktop.org/software/colord/intro.html。基本上是个管理色彩配置的东西,如果你不是特别关心你颜色显示得是否准确,其实有没有都无所谓。 colord发SNMP包还是很难让人理解。ldd看一眼,发现colord并没有链接libnetsnmp,net-snmp也不是他的依赖。 观察一下colord的依赖,其他貌似都挺无辜,但是有个可选依赖是sane。我机子上恰好也装了sane。 sane是啥呢?参见http://www.sane-project.org/,Scanner Access Now Easy(这Now是硬插进去的吧!),是个管扫描仪的东西。 sane倒是依赖net-snmp,所以多半是它干的好事。 之后把colord和sane代码扒下来看一眼,大概知道是怎么回事情了。 说colord有个sane插件,嘛大概扫描仪也需要色彩配置。这个插件会启动一个叫colord-sane的程序,这个程序链接到了libsane。sane有个插件叫magicolor,管理Konika Minolta的一个系列的扫描仪。 colord因为某些原因要更新设备列表,于是调进那个插件。插件启动colord-sane,导致sane也让他的插件们更新设备列表。那个magicolor系列扫描仪估计比较高级,能够联网。magicolor插件更新设备列表就去群发SNMP包,在本地网上找这个扫描仪。这个包被CRF看见了…… 其实也怪那个SNMP请求范围太广。他发的SNMP包基本上就是让本地所有的SNMP设备向他报告自己是啥设备,有啥功能之类。这看上去当然挺危险…… 最后说这个过程是怎么触发的。在开始打记录之后,我发现当我插拔手机/平板的时候,那个记录会一起出现。这种事情很容易联想到UDEV,sane和colord其实都装了UDEV规则,而这里引起问题的是colord的规则。那个规则说,只要USB设备插入/拔出,并且有gphoto支持,就给colord发个通知。Android的手机/平板当然在这个范围,于是引发了一系列事件,最后SNMP包就发出去了…… 总体现象是你插拔手机会发SNMP包,谁知道里面有这么一个过程…… 如果有个工具,能够告诉他触发条件和结果,问他中间的因果关系,倒是会方便不少。好像也不是搞不出来,不过貌似没啥学术价值……

在bsd上跑ndk-build

bsd一直是个官方不咋支持的Android开发平台…… 不过靠着linux兼容层,还是可以混混的…… 首先是ndk-build会报不支持的os(FreeBSD)和arch(amd64),而且ndk-build并不会使用环境变量里定义的值。所以有两个办法: 1. 直接调用gmake env HOST_OS=linux HOST_ARCH=x86 gmake -f $NDK_DIR/build/core/build-local.mk 这样啥都不用改。 2. 修改ndk-build 把HOST_OS设置成linux,HOST_ARCH设置成x86,并且export出来。 再把GNUMAKE设置成gmake,否则会调自带的linux版gmake导致一些麻烦的事情…… 然后直接跑就行了。 跑了之后会碰到一个问题:ld会segmentation fault。看系统log可能是因为fallocate和fstatfs64系统调用没有实现的关系。 解决办法是,到ndk目录里的toolchains/*/prebuilt/linux-x86/…/bin/,如果有ld.gold,那把老的ld干掉,改成到ld.bfd的符号链接。老的ld就是ld.gold…… 其实就是gold那个新的ld调了一些新的bsd还没实现的linux的system call…… 用老的bfd里的ld就没事了……