按这个模型来看，传统 PC-Fi 和 数播，一般是 SCP 三位一体，甚至同一个软件承担了三种角色。对于数播来讲并没有什么不好（现在一部分数播也支持 C 端独立，由另外一台 PC 或者 手机控制），但对于 PC 来说软件系统实在太复杂，对于音频回放不利的不可控因素太多，所以我个人比较倾向于「网桥播放」的方式来进行 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，进行网络流媒体推送。
Roon/HQPlayer + HQPlayer NAA：
电脑上的 Roon/HQPlayer 作为 C + S，树莓派运行 HQPlayer NAA 作为 P。此时做到了 S 和 P 隔离。
我目前比较倾向与最后这种方式。
独立 C 的好处：方便控制尤其是手机。
分离 S 和 P 的好处：因为 S 要进行各种文件读取，网络文件读取、APE/FLAC/DSF 等等格式的解压转码，需要比较复杂的软硬件系统，复杂工作、异步、多任务等等，其实对于对时序和时间精确度高的音频回放是不利的。所以通过和 P 分离，让 P 承担简单、纯粹、完美的 FIFO 数据流转发，以期望得到更好的声音。