WenLink 的「闻」字，是门里一只耳朵。小店叫「门耳朵」，这个协议也就顺着叫了这个名字：把声音从门这边，原原本本地送到门那边的耳朵里。
WenLink 同时做到三件事：
- 什么应用的声音都能送：Roon、Audirvana、Qobuz、TIDAL、QQ 音乐、Apple Music，浏览器里的 YouTube 演出，都可以。播放器支持独占模式就更好，系统里的其他声音混不进来，bit-perfect 更有保证；
- 延迟只有 20 ms 左右：看视频口型对得上；
- bit-perfect：一个比特都不改，原生 DSD 直达 DAC。
三件事单独做到一两件的方案很多：AirPlay 什么都能送，但不是 bit-perfect；RAAT、NAA 是 bit-perfect，但只送自家播放器的声音。三件事同时做到的，网络音频里只有专业录音棚用的 Dante，它需要专门的硬件。面向家用 HiFi，我找了一圈，只有 WenLink。
一、为什么要做它
我的 DAC 在客厅，Mac 在书房。Roon 的曲库有 RAAT，但 Mac 上还有别的音源：Qobuz、TIDAL、Apple Music 的客户端，Audirvana 之类的播放器，还有一些只在电脑上才有的高解析文件和 DSD。还有一样常被忽略：晚上在 YouTube 上看一场演出，音乐会、爵士现场、歌剧，声音也值得走那套好系统。我想让这些声音都像 Roon 一样，一个比特都不改地走进那台 DAC，看视频时口型还要对得上。
翻了一圈现成的方案，都差一点：
- AirPlay：什么都能送，但上限是 16 bit / 44.1 kHz，高解析一律被降采样，DSD 更谈不上；延迟约 2 秒，看视频全靠播放软件去补偿。
- USB 线：音质最直接，可是拉不到客厅。
- UPnP / DLNA、LMS：只认文件，客户端里的流媒体送不过去。
- 网络传声的老方案（比如 Scream）：能送，但没有时钟同步，隔一阵就会爆一声。
所以我自己做了 WenLink。
二、HiFi 听友关心的几件事
比特有没有被动过？
没有。WenLink 对「bit-perfect」有明确的定义：从系统收到的每一个样本，全部有效位原样到达 DAC。唯一允许的变换是把 16 bit 样本放进 32 bit 容器、低位补零，这是无损、可逆的。重采样、混音、抖动、截断、软件音量，一概不做。
- 接收端直接打开 ALSA 的
hw:设备，不经过 PulseAudio、dmix 或任何格式转换层。 - WenLink 声卡本身没有音量控制，系统没法对它做软件衰减，音量请交给功放或 DAC。
- 这不是一句口号：测试时，接收端写进 DAC 的数据与源文件逐字节比对，全部一致（见第四节）。
时钟听谁的？
只听 DAC 的。 这是 WenLink 最核心的设计。
Mac 和 DAC 各有各的晶振，两颗晶振不可能完全一样快，通常差十几到几十 ppm。拿我自己的 aqua xHD 2.0 来说，Mac 比它的 44.1k 系时钟快约 24 ppm，比 48k 系快约 6 ppm；两族差得不一样，因为 Aqua 给两个采样率族各配了一颗晶振。差 20 ppm，听起来微不足道，可放任不管，缓冲迟早会被吃空或撑满，结果就是隔一阵爆一声或断一下。
播放软件自己的传输方案没有这个烦恼：RAAT、NAA、DLNA、LMS 单个房间播放时，都由 DAC 一侧的时钟决定节奏，不需要改动样本。可它们只管自己播放的音乐。要把系统里实时产生的声音推出去，比如网页、视频、任意播放器，就绕不开两颗晶振的问题。这时常见的做法是放任不管（Scream），或者在接收端增删样本、重采样去对齐（开源的 AirPlay 接收端 shairport-sync、Snapcast 都是这样）。不爆音了，可比特已经变了。
WenLink 反过来做：DAC 的晶振是唯一的标准，其他都跟着它走。 接收端一直盯着 DAC 实际播放的位置，算出 Mac 比 DAC 快了还是慢了多少，每 20 ms 告诉 Mac 一次。Mac 上的虚拟声卡按这个修正量把自己的节拍调快或调慢一点，系统就按这个节拍送数据。
调的是节拍，不是样本。在系统和播放器看来，WenLink 只是一块晶振略有偏差的声卡，就像任何一块真实的声卡一样；送出去的每个样本都和原来一模一样。
这一个设计，同时管住了三件事：
- 音质：不需要重采样。异步重采样要经过一次数字滤波和重新量化，送到 DAC 的已经不是原来的比特；WenLink 从头到尾不碰样本。
- 看视频：时钟不漂，延迟就不漂。放任两颗晶振各走各的，延迟会一点点变大或变小，看到后半场口型就慢慢对不上了；WenLink 的延迟从第一秒到最后一秒都是同一个值，这个值又上报给了系统，声画才能一直对齐。
- 全局生效：这件事做在「声卡」这一层，不在某个播放器里。Roon、Audirvana、Apple Music、浏览器里的 YouTube、视频软件，凡是往 WenLink 发声音的应用都一样受益，不需要应用做任何配合。
这和 USB 异步模式是同一个思路：DAC 做主，源端跟随。网络传输的抖动只落在接收端的缓冲里，不会变成 DAC 的时钟抖动。
高解析和 DSD 能到多少？
- PCM：44.1 kHz 到 384 kHz，44.1k 系和 48k 系都支持；16 bit、24 bit。
- DSD：原生 DSD64、DSD128，两个系列都支持。Mac 上的播放器只能以 DoP 方式送 DSD，WenLink 在 Mac 端把 DoP 拆回原生 DSD 比特再发出，接收端以原生 DSD 写进 DAC。DAC 收到的是原生 DSD，不是 DoP。
- 只开放 DAC 原生支持的格式：接收端会告诉 Mac，这台 DAC 能原样播放哪些采样率和位深，Mac 只向系统开放这些格式。系统不会以为自己在播 384k，背地里却被某一层悄悄转换了。
电脑和 DAC 是分开的
DAC 不再插在电脑上，而是插在一台只做这件事的小接收端上，电脑可以放在另一个房间。电脑和 DAC 之间只有一根网线，不再通过 USB 共地。家里有两台 Mac，也可以共用一台 DAC：谁先播谁用，停下 2 秒后另一台才能接手，切歌时不会被抢走。
信号路径看得见
每一个流是否 bit-perfect，接收端都会如实报回 Mac。只要有一帧因为网络问题被补偿过，状态就会变，并且记下补偿了多少帧。在 Mac 上用 wnlctl status 就能看到：接收端是否在线、接的是哪台 DAC、当前格式、这个流是否 bit-perfect。
看演出视频，口型对得上
在 YouTube 上看一场现场，声音和画面差一点点都会出戏。WenLink 的端到端延迟稳定在 20 ms 左右，而且这个值是恒定、已知的：
- 时钟跟着 DAC 走（见前面「时钟听谁的」），延迟不会越播越大，也不会越播越小。看一场两小时的歌剧，结尾和开头一样准。
- 延迟会上报给 macOS。系统的视频框架拿到的呈现延迟与上报值完全相等，播放器据此推迟画面，声画自然对齐。
- 就算某个播放器不理会这个上报值，20 ms 的差距也在人察觉不到的范围里。广电行业通常要求声音比画面晚不超过 60 ms 左右。
这一点上，WenLink 和 AirPlay 的差别比音质还大，第五节会细说。
三、它是怎么连起来的
Mac 上的播放器 → WenLink 虚拟声卡 ──网线──▶ 接收端 ──USB──▶ DAC
◀── 时钟校正、DAC 能力、bit-perfect 状态 ──- Mac 端：一个 Core Audio 插件，在「声音」设置或播放器的输出设备里选 WenLink 即可，不需要内核扩展。
- 接收端：一台小设备（我用的是 BeagleBone），USB DAC 插在它上面。
四、实测数据
日常聆听：aqua xHD 2.0。 在我自己的系统上，BeagleBone 接收端接 aqua xHD 2.0，正常播放了 49 分钟、11 个流，期间只读观察，不做任何干预：
- 11 个流全部 bit-perfect（24 bit 样本放进 32 bit 容器、低位补零）；
- 约 31 万个包，丢包、乱序、迟到、补偿、DAC 欠载全部为 0；
- 实际延迟 16.9–17.4 ms，目标 17 ms；
- 同一采样率开始新的曲目，开头一个样本都没被截掉；
- 接收端探测到的能力：PCM 44.1k–384k，16 / 24 / 32 bit 全部能原样播放；原生 DSD64 / 128，44.1k 系和 48k 系都支持。
压力与长测：测试机。 下面这些是在专门的测试机上做的（BeagleBone 接收端 + 一台测试用的 USB DAC，有线局域网）：
- 逐字节一致：Roon 经 WenLink 播放 PCM 44.1k–384k 和 DSD64 / 128，接收端写进 DAC 的数据与源文件逐字节比对，全部一致。
- 时钟锁定：开始播放后 1–6 秒锁定。锁定后延迟误差 p99.9 在 0.1 ms 以内；学到的时钟偏差稳定在 ±0.05 ppm 以内。
- 长时间：1 小时连续播放，142 万个包零迟到、零补偿；12 小时常态长测，DAC 零欠载。
- 断网与睡眠：播放中拔掉网线约 10 秒，插回后自动续上；接收端重启、Mac 睡眠唤醒后都能自动恢复。
五、和主流数播协议比一比
先放一张总表，后面逐个说。表里写的是各协议的常见用法，具体表现还要看设备和设置。
| 协议 | bit-perfect | 谁做时钟 | 高解析与 DSD | 能送什么 | 延迟 | 多房间 | 开放程度 |
|---|---|---|---|---|---|---|---|
| WenLink | 是，逐流报告 | DAC，电脑跟随 | PCM 到 384k；原生 DSD 到 DSD128 | Mac 上任何应用，含网页视频（Windows 待做） | 约 20 ms，恒定，上报给系统 | 不支持 | 自研 |
| Roon RAAT | 单区是，有信号路径显示 | 端点 DAC | 视端点而定 | Roon 里播的内容 | 秒级缓冲 | 支持 | 闭源，需 Roon 订阅 |
| HQPlayer NAA | 可以直通，主打升频 | 端点 DAC | 高倍率 DSD（视 DAC 与主机） | HQPlayer 里播的内容 | 有缓冲，可调 | 不支持 | 闭源，付费 |
| Diretta | 是 | 端点（Target） | 支持 | 搭配的播放软件 | 有缓冲 | 不支持 | 闭源，Target 收费 |
| UPnP / DLNA | 取决于渲染器 | 渲染器本地 DAC | 视渲染器 | 文件和流媒体 | 秒级 | 部分实现支持 | 开放标准 |
| LMS（slimproto） | 单区播放可以 | 播放器本地 DAC | 视播放器 | 文件和流媒体 | 秒级 | 支持，同步时各播放器自行补偿漂移 | 开源免费 |
| AirPlay 2 | 不是：ALAC 16 / 44.1，或 AAC 有损 | 接收端对齐发送端（如 shairport-sync 增删样本或重采样） | 不支持高解析与 DSD | 苹果设备上任何应用 | 约 2 秒 | 支持 | 闭源 |
| AES67 / Dante | 是 | 网络上的 PTP 主时钟 | 不支持 DSD | 专业音频多声道 | 亚毫秒到数毫秒 | 支持 | AES67 开放，Dante 授权 |
| Snapcast | 不是，靠跳过、补静音或变速对齐 | 服务器时间 | 不支持 DSD | 送进服务器的任何音频 | 数百毫秒 | 支持（主打） | 开源 |
| Scream | 不保证 | 没有同步 | 不支持 DSD | Windows 上任何应用 | 低，但会漂 | 组播可以 | 开源 |
数据完整性：比特到没到、对不对、你知不知道
「数据完整」其实分三层：包有没有到齐；到齐的是不是原来的比特；出了问题，你能不能知道。每个协议在这三层上的表现并不一样：
| 协议 | 包有没有到齐 | 是不是原来的比特 | 出了问题你能知道吗 |
|---|---|---|---|
| WenLink | UDP，每包带序号；不重传，丢包一定检测到 | 是，从头到尾不碰样本 | 能，逐流报告，可逐字节比对 |
| Roon RAAT | 有缓冲，具体传输方式未公开 | 单区可以 | 能，信号路径显示 |
| HQPlayer NAA | TCP，丢了重传 | 直通时原样；常规用法是升频，内容被有意改变 | HQPlayer 里能看到 |
| UPnP / DLNA、LMS | HTTP（TCP），文件完整到达 | 取决于渲染器或播放器；LMS 多房间同步时要补偿漂移 | 看具体设备 |
| AirPlay 2 | 实时模式统计迟到和丢包 | 不是：实时模式 ALAC 16 / 44.1，高解析先降采样；缓冲模式是 AAC，有损，由发送端选；还有软件音量 | 用户看不到 |
| Snapcast | TCP | 不是：默认 FLAC 无损，但同步时会跳过、补静音、变速；也可以选有损编码 | 不报告 |
| AES67 / Dante | RTP（UDP），不重传，靠受管网络不丢包 | 正常时是 | 专业设备有统计 |
| Diretta | 查不到公开资料 | 宣称是 | — |
| Scream | UDP，没有序号 | 不保证 | 不能，丢了都不知道 |
有一点要说在前面：在「包有没有到齐」这一层，拉文件、走 TCP 的方案比 WenLink 更强，丢了会重传，你根本察觉不到。WenLink 没有选重传，因为重传要留出大缓冲，就做不到 20 ms 的延迟，看视频口型就对不上了。它的底气来自两点：
- 有线局域网本身不丢包。 实测 156 万个包零丢包；1 小时 142 万个包零迟到。真丢包只发生在链路被大流量塞满时，那时延迟已经多出几十到上百毫秒，重传也来不及。
- 一旦出事，一定让你知道。 哪怕只补偿了一帧，这个流的 bit-perfect 状态就会变，补了多少帧也记得清清楚楚，不会悄悄带过。
回到开头那三件事：在「什么应用的声音都能送、延迟只有 20 ms」的方案里，能做到 bit-perfect 的只有 WenLink 和 Dante，而家里的 DAC 很少带 Dante 接口。这就是 WenLink 存在的理由。
Roon RAAT
听 Roon 曲库，RAAT 依然是我最推荐的方式：信号路径清清楚楚，曲库、元数据、多房间都做得成熟。单区播放时，Roon 按端点 DAC 的时钟发送，和 WenLink 是同一个思路。
区别只在边界：RAAT 只送 Roon 自己播放的内容；多房间分组时，其他区要向主时钟对齐、补偿漂移。WenLink 做在系统声卡这一层，什么应用都能用，也不做多房间。两者可以装在同一台接收端上：Roon 一开播，大约 1 秒就接管 DAC；Roon 播完后，WenLink 不会自动恢复。
HQPlayer NAA
NAA 是 HQPlayer 的网络端点，DAC 时钟做主，电脑与 DAC 之间用异步缓冲隔开，思路和 WenLink 相近。区别在于它和 HQPlayer 绑在一起，而 HQPlayer 的长处在升频和滤波，追求的是「算出更好的信号」。WenLink 追求的是「原样」，什么都不算。两种取向没有高下，看你想听哪一种。
Diretta
Diretta 的重点是让发送端以恒定的短间隔发包，平滑终端的处理负载；它认为负载的波动会干扰声音。它需要专门的 Target 端（收费），为播放软件的音乐链路服务。
我的取舍不一样：先保证数据，再谈其他。 数据错了，再平滑也没有意义。WenLink 的每个包都带序号，丢没丢、晚没晚、有没有被补偿，接收端都会记下来并报回给你；写进 DAC 的数据，可以拿来和源文件逐字节比对。负载平滑对声音有多大影响，目前还缺少公开的测量；比特对不对，却是可以证明的。所以 WenLink 不在发包节奏上做文章，力气都花在两件能验证的事上：比特原样，时钟跟着 DAC 走。
UPnP / DLNA 与 LMS
这两类都是「拉文件」：渲染器或播放器自己从服务器取文件、自己解码、按本地 DAC 的时钟播放，所以天然没有时钟漂移的问题，播文件也可以做到 bit-perfect。它们的局限在于只认文件和流媒体协议，电脑上播放器、客户端发出的声音送不进去。
LMS（现在叫 Lyrion Music Server，搭配 squeezelite）开源免费，多房间做得好。多房间同步时，各个播放器要自己补偿彼此的时钟漂移，这时就很难保证 bit-perfect 了。
AirPlay 2
AirPlay 是和 WenLink 用法最接近的：系统级，什么声音都能送，苹果设备上开箱即用。也正因为用法一样，两者的差距最直观，音质和延迟两头都差得很远：
| AirPlay 2 | WenLink | |
|---|---|---|
| 格式上限 | 16 bit / 44.1 kHz ALAC，高解析被降采样 | PCM 到 384 kHz / 24 bit，原样传 |
| 编码 | 实时模式 ALAC 无损；缓冲模式 AAC 有损，由发送端决定 | 不编码，原始 PCM 或原生 DSD |
| DSD | 不支持 | 原生 DSD 到 DSD128 |
| bit-perfect | 不保证，音量是软件调的 | 是，逐流报告，没有软件音量 |
| 时钟 | 接收端对齐发送端的时钟（如 shairport-sync 增删样本或重采样） | DAC 晶振做主，电脑跟随 |
| 延迟 | 约 2 秒 | 约 20 ms，恒定 |
| 看视频 | 要靠播放软件补偿那 2 秒，补偿不了就声画错位 | 即使不补偿，20 ms 也察觉不到 |
AirPlay 的强项在多房间和随手可用，iPhone 上点一下就能放。坐下来认真听、认真看一场演出，WenLink 是更好的那条路。
AES67 / Dante
这是录音棚和演出场馆的协议：网络上有一个 PTP 主时钟，所有设备锁到它上面，延迟可以做到亚毫秒，几十上百个声道同步。论严谨，它在这张表里数第一，可它需要专门的 Dante 或 AES67 硬件，家用 HiFi DAC 很少带这种接口，也不支持 DSD。而且 DAC 锁的是网络上恢复出来的时钟，不是它身边那颗晶振。
Snapcast
Snapcast 的目标是全屋多房间同步：每个客户端持续和服务器对时，偏了就跳过一段、补一段静音，或者略微变速播放，把各个房间对齐到 1 ms 以内。为了同步，它主动放弃了 bit-perfect，和 WenLink 的取舍正好相反。
Scream
Scream 是 WenLink 的前身，一块开源的 Windows 虚拟声卡，把音频打成 UDP 包发出去，简单到 ESP32 都能当接收端。它的问题也来自简单：没有序号，没有时间信息，没有时钟同步，长时间播放必然隔一阵爆一声。WenLink 最早就是从「把 Scream 做成 HiFi 级」开始的，现在已经在固件里取代了它。
六、和 USB 直连比
这个比较最有意思，因为WenLink 的时钟原理就是 USB 异步模式，只是搬到了网线上。
USB Audio Class 2 的异步模式里，DAC 用自己的晶振，通过「反馈端点」告诉电脑多送一点或少送一点。WenLink 的 FEEDBACK 报文做的是同一件事：每 20 ms 一次，接收端告诉 Mac「快了」或「慢了」。而且从接收端到 DAC 这一段，本来就是一根 USB 线。
| USB 直连 | WenLink | USB over IP（如 USB/IP） | |
|---|---|---|---|
| 时钟 | DAC 做主，反馈端点 | DAC 做主，FEEDBACK 报文 | DAC 驱动在电脑上，USB 的时序要跨网络往返 |
| bit-perfect | 可以 | 可以，逐流报告 | 理论上可以，断续时就不是 |
| DSD | 取决于 DAC，可以到 DSD512 以上 | 到 DSD128 | 取决于 DAC |
| 电脑与 DAC 的电气连接 | 直接相连、共地 | 中间隔着网线和接收端 | 中间隔着网线 |
| 距离 | 一般 5 米以内 | 局域网能到的地方 | 局域网能到的地方 |
| 多台电脑 | 要插拔线 | 先到先得，自动切换 | 一次只能挂到一台 |
| 延迟 | 几毫秒 | 约 20 毫秒 | 不稳定 |
| 需要什么 | 一根线 | 一台接收端 + Mac 插件 | 两端都装软件 |
说句实话：如果 DAC 就在电脑旁边，USB 直连更简单、延迟更低，也能上更高的 DSD 倍率，没必要用 WenLink。 WenLink 是为「电脑和 DAC 不在一处」准备的。
USB over IP 把 USB 协议本身搬到网络上，听起来最省事，实际上不适合音频。音频走的是 USB 的等时传输，对时序很敏感，每一次「多送一点」的反馈都要在网络上走一个来回，网络稍有抖动就会断续。WenLink 只在网络上传音频和反馈，USB 这一段留在接收端本地，时序问题不会跨过网络。
七、它做不到的事
这些是有意的取舍，写在这里，免得你装上才发现：
- Mac 端最高 24 bit 有效位。 macOS 内部用 32 位浮点混音，32 bit 整数没法原样往返。这是 macOS 的限制，所有 Mac 上的播放器都受它约束，不只是 WenLink。
- DSD 最高到 DSD128。 接收端是一台小设备，为了稳定，目前把原生 DSD 限制在 DSD128。想听 DSD256 及以上，请用 USB 直连。
- 只有立体声。 多声道到了双声道 DAC 只能下混，下混就不是 bit-perfect 了。
- 必须有线，而且网络别太挤。 实测在正常的家用有线网络里不丢包。但如果同一条链路被下载等大流量塞满，延迟会多出几十到上百毫秒，声音就会断续。音频最好不和大流量挤同一个百兆口。Wi-Fi 没有测过，不推荐。
- bit-perfect 要靠播放器配合。 系统里其他声音混进来，或者播放器自己做了转换，WenLink 原样送到的就是转换后的内容。播放器请开独占模式，并让它按曲目切换采样率。Apple Music 没有独占模式，也不会按曲目切换采样率：要原样播放，得避免系统里同时有别的声音，并在「音频 MIDI 设置」里把 WenLink 手动设成曲目的采样率。
- 和 Roon 一起用时要注意独占。 Roon 开着独占模式时，系统其他声音用不了 WenLink。听 Roon 曲库，建议直接走 RAAT。
- 只能在家里的可信网络用。 协议没有加密和认证。
- 不做多房间。 一台接收端同一时刻只为一台电脑出声。
八、现在做到哪了
| 部分 | 状态 |
|---|---|
| macOS 播放端 | 已可用。Roon 下 PCM 与 DSD 各格式逐字节一致，TIDAL、Apple Music 实测可用；断网、接收端重启、睡眠唤醒都会自动恢复 |
| 接收端 | 已集成进桥接固件，和 Roon Ready、AirPlay 并列作为一个音源。测试版，还没有正式发布 |
| Windows 播放端 | 待做。前期验证正在进行 |
| Linux 播放端 | 暂缓 |
WenLink 还在开发和测试阶段，一些细节仍在打磨。Windows 版和固件正式版出来时，我会在这里更新。想先试试 Mac 版，或者想聊聊数播，欢迎进主页的群。