今天说说系统发快递，乱弹纯技术贴，细说NS200的软件优化
本帖最后由 andygaof 于 2019-12-10 23:38 编辑这几天经常有人想详细了解NS200的优化细节。本身CelWare3是个开放系统，这里就详细说说NS200的优化理念和具体实现方法。
先说观点：核心两个字就是“实时”。今天就乱弹一下，以发快递的例子来说说系统优化的事
音频回放对实时性的要求极高，即便是有很多层级的缓存，但是任何的有利于提升实时性的优化手段都会对声音带来明显的改善。也就是说，听音乐跟收快递一样，你收快递越快越及时，你的感觉就越好。
同时在具体优化上，在不严重影响到CPU利用率的前提下，硬件调度处理实时性优先于软件处理实时性。
为什么是硬件？下面看一下优化过后的一个实例。UPnP播放流媒体音乐到USB解码器的例子，播放一个44.1KHz的音频。
看一下负责播放和接收数据的两个进程MPD，UpMPDcli，两个进程加一起CPU占用率仅1.7%，而负责通过USB向解码器发送数据的进程的CPU占用率高达5.3%。另外一个原因会在硬件调度后和单端软件优化的对比分析里提到。详见三楼。
本帖最后由 andygaof 于 2019-12-10 23:36 编辑
先说最简单的软件优化。思路很简单
1. 发快递的人越少越好，这样快递小哥可以早点来：尽可能少的部署处于活动状态的软件：这个与你的软件系统具体有多大没有关系，而是与有多少个软件在活动，以及这个软件占用的硬件资源有关系。哪怕是有100G的系统，但是在同一时刻只有一个软件在运行，而且这个软件的运行效率极高，那么这个系统的效率都会很高。
在实际的部署中，CelWare最终会支持ROON，HQPlayer，UPnP Server，UPnP Render，AirPlay，甚至已经开始考虑支持视频回放功能。因此CelWare本身是个体积比庞大的系统，但是每个具体功能都可以通过界面配置打开与关闭。例如使用Roon的时候可以关闭其他所有的音乐应用。所以CelWare实际处于活动状态的软件非常少。
2. 我要当VIP，下了单，快递小哥先紧着我的包取：尽可能的提高音乐进程的优先级：将音乐软件进程至于应用软件优先级的最高层级，使用实时（rt）级别的优先级。这个实现起来非常简单。而且，在每次打开应用软件时，例如用ROON听了一会本地曲目后，突然想通过QPlay听听最近流行的某个口水歌，临时打开UPnP Render功能，系统会在打开的同时将UPnP Render功能的优先级调度到最高的实时（rt）优先级。
如上图所示，这是一个使用Roon播放DSD64的场景，无论多少次的打开与关闭Roon Server，CelWare会保证Roon Server（Linux进程名RoonApplicane）处于RT调度优先级。 这里不是优化后的结果，只是软件部分处理之后的结果，最终优化水平请看三楼。
本帖最后由 andygaof 于 2019-12-10 23:51 编辑
在说最为复杂的硬件优化，前面提到过，硬件优化的重要性大于软件调度。在开篇中多次强调“实时”，但是“实时”并不是采用了RT内核就万事大吉的。
1. 叫不同级别的快递：分离系统IRQ中断调度，并处理优先级。
无论是否采用RT内核，在不做进一步处理的情况下，应用软件想要通过硬件向其他设备发送数据，例如ROON Server通过网络向ROON Bridge发送数据，或者UPnP Render通过USB向解码器发送的时候，都会向系统请求占用硬件资源。系统在一系列的处理后告诉应用软件把数据丢到一个统一的调度堆栈里，然后统一进行调度。
就好比是发快递，你把包裹交给顺丰的快递小哥，然后他会收集所有的包裹，再送到仓库里，等着统一处理。
负责接收“快递”的顺丰“小哥”
而经过处理后，应用软件会直接向某个资源写入数据，然后直接发送。
这就好比是发闪送，你直接叫一个一对一的快递，专门数据点对点直达
负责接收“快递”的闪送“小哥”
更进一步，以USB播放NAS上的音乐文件优化实例描述，系统一共叫了两个闪送“小哥”，一个是负责送USB数据的，一个负责取NAS数据的。这个两个闪送小哥都拥有极高的优先级，（连接解码器的USB 90，连接NAS的以太网口85），而同样负责发送顺丰级USB数据的另外一个USB接口的优先级跟其他人一样只有50。
2. 给够级别级别人分配专享快递员，配专享快车道，永远不会有意外：CPU分离
重要的闪送哥给一个专用的通道，分一个专有的CPU给他。以UPnP播放音乐为例
这是系统开始播放一段时间的图，红色的是系统启动盘活动次数。红色的系统盘一开始由系统自动分配给CPU2负责管理（具体会分配给谁不一定），调度系统启动后被CelWare调度给CPU3负责（原因等下再说），绿色的是USB解码器，一开始由CPU1负责（具体会分配给谁不一定），调度系统启动后交给CPU2负责。蓝色的网络一开始由CPU1负责，调度系统启动后由CPU2负责。
这是系统继续播放了一段时间的结果。我们重点关注一下黄色框里的数据，这个数据是系统中断被临时从新安排发包顺序的次数。也就是说，对音乐播放非常重要的的USB口和以太网口，其中USB发送了2.3万多个（62003-38691）中断，一次都没有发生重新调度（原有的100多次是调度系统启动前的数字，调度系统启动后这个数据就没动过），而CPU0和CPU1的重新调度次数每个高达4000次以上。同时系统盘被访问的次数只有区区的不足80次。
也就是说其他不重要的软件想发快递的时候被系统放了总计8000多次将近9000次鸽子，而重要的软件想发快递由于是专人专用，一次都没有被放鸽子。
3. 最后的对比，大吃一惊的结果。最后回过头来对比看仅优化软件里的那一张图。
经过良好硬件调度处理后，播放同一个DSD曲目，ROON 占用了三个CPU核心，CPU0，CPU1，CPU2由于读取的是本地硬盘的数据，CPU3专门负责网络传输，CPU占用率稳定在0.7%，但是相比二楼，CPU0/1/2的利用率从原来的40%多锐减到10%左右。（ROON不需要花费时间等待硬件队列，效率反而明显提高了。）
尽管经过硬件处理后，所有的IRQ都线程化增加了大量的系统线程。（从一百多个增加到一百五十多个），但是其优化的结果是显而易见的，在播放DSD64的情况下，整个系统CPU占用率仅10%左右，而且所有的音乐数据全部“实时”转发。因此坚持硬件优化优先于软件优化的原则。
说了那么多，到底ROON和UPNP哪个音质好:lol
另外，UPNP不一定要走USB的吧，也可以走网口啊，配合PNA使用的情况下，我觉得走了USB就不符合CORE和桥分开的搭配了，按理音质应该不如分开搭配的好
然而Roon是用C#写的，在Linux下运行天生比Windows弱三分。
一个很简单的例子，Roon大量使用了线程，而Linux是没有线程的 本帖最后由 je22e0t1an 于 2019-12-11 07:57 编辑
音频回放对实时性的要求极高，即便是有很多层级的缓存，但是任何的有利于提升实时性的优化手段都会对声音带来明显的改善。也就是说，听音乐跟收快递一样，你收快递越快越及时，你的感觉就越好。
然而有资料说明操作系统调度实时性（RT）和音质并无关联，来自MPD的引用：（MPD也就是当今大部分基于linux的播放软件的基础/核心组件，比如 moode、volumio、rune 等等）
Note There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load.
来源：https://www.musicpd.org/doc/html/user.html#real-time-scheduling
隔壁Brain说系统是自己构建的Linux系统，经过极致优化后，压缩包才135m左右；
不知道高总的和这个比怎么样？ 我也好奇，实时对于音质是否很重要，比如播放在线的tidal，相对于云端文件，肯定经过很遥远多次的缓存，但是播放音质与本地播放事实上没有实质区别。 本帖最后由 darkfrank 于 2019-12-11 09:37 编辑
前一陣子研究國外那個收費Audio-Linux時，這些設置基本全都有，可以算是在Archlinux裡用來提升服務效率的比較基本的優化手段，期待分享更深入的優化手段:lol yuotube 发表于 2019-12-11 01:22
说了那么多，到底ROON和UPNP哪个音质好
另外，UPNP不一定要走USB的吧，也可以走网口啊，配合PNA使用的 ...
走USB，以太网都可以，配合PNA自然是走网口。我只是举例说明的时候用了USB的例子。
至于ROON和UPnP那个好，我觉得见仁见智吧，两个播放软件相比之下，UPnP线条和瞬态略好，而ROON细节更丰富一些。我个人口味上，古典我倾向于ROON，流行我更喜欢UPnP一点。 :lol:lol:lol:lol 为何ROON 和UPnP还有这么大差别？
页:
[1]
