网桥播放模型

aligo

先定义一下 PC-Fi 的「网桥播放」：

1、通过网络传输来隔离 PC  和 DAC 连接
2、音频文件来自 PC 本机、内网共享、互联网

网桥播放一般包含如下成员：

1、[S] 服务端，一般就是 PC，主要作用是读取、解码音频数据至 PCM/DSD 格式，通过网络协议包装送交播放端。但可以发送给另外一个服务端进行 Rerender，只要求最终输出是 PCM/DSD 即可。
2、[C] 控制端，一般就是 PC，通常和服务端在一起，现在也可以是手机，连接服务端（如果在同一台机器，就不通过网络，甚至就是同一个软件），对音频回放进行控制。
3、[P] 回放端，与 PC 隔绝，直接 DAC（一般是 USB），接收 PCM/DSD 网络数据流，仅可能简单少处理无污染地交给 DAC。

按这个模型来看，传统 PC-Fi 和 数播，一般是 SCP 三位一体，甚至同一个软件承担了三种角色。对于数播来讲并没有什么不好（现在一部分数播也支持 C 端独立，由另外一台 PC 或者 手机控制），但对于 PC 来说软件系统实在太复杂，对于音频回放不利的不可控因素太多，所以我个人比较倾向于「网桥播放」的方式来进行 PC-Fi。

几乎所有 PC-Fi 有关的播放方式，都可以套用这个模型来进行分析，通过分析其所用协议、经过的转换的次数和节点，可以帮助我们建立一套好用方便的系统，同时对薄弱、有损回放质量的环节进行设置、调整、控制、替换。

把几种手机上的网络推送方式套用到该模型中：

蓝牙：
手机作为 C + S，接受设备作为 S + P，工作方式是 C + S > 蓝牙音频协议 > S + P，但是蓝牙网络协议带宽不足，所以音频传输时候有压缩，再接收设备上转换回 PCM 进行回放。

AirPlay / DLNA 有两种方式：
一种和蓝牙类似，手机作为 C + S，接受设备作为 S + P，工作方式是 C + S > 对应协议 > S + P，而 AirPlay/DLNA 可以走多种格式进行传输，协议里有约定每个接受端需要广播自己的名字、IP 地址、包括支持的格式等等，DLNA 接收端一般都支持 PCM，但 AirPlay 倾向于使用 AAC 格式。

另一种是由手机作为 C，接受设备作为 S + P，这种方式一般称为网络推送播放，需要接收端声明自己支持的格式、服务方式，手机不持有音频文件，只是将音频文件的地址、播放控制信息方式到接收端，由接受端转码播放，送入 DAC。工作方式就是
C 控制，S 直接拉取网络数据 > P。

现在还有一些解码支持简单的网桥播放，接受 PCM/DSD，算是整合 P 端 ( P -> DAC )，而如果支持比较高级的 蓝牙、AirPlay、DLNA 等，即算是整合了 S 与 P ( S -> P -> DAC )，可以由电脑或手机上的 S 发送音频数据，甚至电脑或手机作为 C，进行网络流媒体推送。


运用树莓派们可以做的网桥播放方式：

单独树莓派们作数播：
树莓派上运行的网页或者手机软件作为 C，树莓派上的 MPD 等后端软件作为 S + P，如果树莓派上有 upmpclid 等，通过手机上的 bubbleupnp 可以进行 spotify、tidal、qq 音乐等的 DLNA 推送。

Roon/HQPlayer + HQPlayer NAA：
电脑上的 Roon/HQPlayer 作为 C + S，树莓派运行 HQPlayer NAA 作为 P。此时做到了 S 和 P 隔离。


我目前比较倾向与最后这种方式。

独立 C 的好处：方便控制尤其是手机。
分离 S 和 P 的好处：因为 S 要进行各种文件读取，网络文件读取、APE/FLAC/DSF 等等格式的解压转码，需要比较复杂的软硬件系统，复杂工作、异步、多任务等等，其实对于对时序和时间精确度高的音频回放是不利的。所以通过和 P 分离，让 P 承担简单、纯粹、完美的 FIFO 数据流转发，以期望得到更好的声音。

以上是我目前的想法。

aligo

但是对于 Roon/HQPlayer + HQPlayer NAA 的实现，目前我只用过树莓派，树莓派对我来说不完美的地方：

一个是电难搞好；
一个是树莓派的网络接口和 USB，共用一条 USB 2.0 480Mbps 的总线，总觉得和 DAC 和 网络 在带宽占用高的时候会被互相影响，树莓派三代的 WIFI 模块倒是独立不用这个带宽，但是连接一直不太稳定。

同时 HQPlayer NAA 我这么用，实际上为了追求 bit-prefect，舍去了它所有的升频、数字滤波功能，其实完全也可以有一个更精简的协议来代替，目前没找到。

zchgoood

写的很好 收藏了~~~理清思路