耳机网-耳机大家坛

标题: Linux音频系统中的延迟优化实践,兼谈preempt rt和augomagic preemption [打印本页]

作者: 中关村东路    时间: 2023-11-4 01:34
标题: Linux音频系统中的延迟优化实践,兼谈preempt rt和augomagic preemption
经常看到有烧友说hifi要降低延迟。很多动手能力强的烧友用上了daphile、snakeoil os、audiolinux/gentooplayer等的rt内核,用上了hqplayer os的低延迟内核,甚至是xenomai内核。有的烧友强化路由器和交换机的性能,获得更低的网络延迟。还有些公司使用带有特别低延迟控制单元的soc,如Bricasti M5/M21用了TI的pru。本帖首先简单介绍这些降低延迟的方案和音频回放的关系,之后介绍我实践的Linux音频系统低延迟优化方案。

1. 什么是延迟,为什么要rt
2. 硬件因素
3. 内核补丁
4. 内核设置
5. 软件设置
6. 小结


作者: 中关村东路    时间: 2023-11-4 01:35
1. 什么是延迟,为什么要rt

我们把上述例子中的延迟分为三类:一类是网络延迟,顾名思义不详细解释了;一类是回放系统,如网桥中的cpu latency,也就是播放指令从ALSA驱动发出,到任务提交给了解码器的这个小周期;第三类是控制精度或latency,指的是对自己控制指令发放时间和实际时间的误差限,比如我问系统几点了,他告诉我一个时间,在windows上的误差大约是十几毫秒,而在xenomai和TI pru上数量级是10us。

这些延迟的例子中,网络延迟在玩游戏放视频中对体验影响很大,但其实一般认为对音频回放质量几乎没有影响,举个和我没有商业利益关系的某数播的例子(真没有),很多人说他家的数播软件做的很好,我没听过但知道大致原理,他播放音乐前要把所有数据缓冲进内存,转换了格式再播放,而并不会因为我或早或迟点击开始按钮,或者数据缓冲了多久而改变音质。网络延迟别到了延误的地步就够。

各类rt内核,低延迟内核,xenomai内核以及Bricasti等使用的TI pru单元等硬件是控制latency的例子。这在机器人控制等方面是极其重要的指标,因为机器人控制算法几乎都是闭环控制(close-loop),也就是算法中当前时间的控制量是当前时间、以及当前时间可观测到的系统状态的函数,但在音乐流式回放这种开环结构中影响并不大。

有人说你不是说好了三类延迟吗,怎么两类就把所有例子都用完了,cpu延迟呢。控制精度的提升,总是和cpu延迟的降低分不开的。但很遗憾的是,其中只有hqplayer os使用的低延迟内核和preempt rt内核两类是通用方案,只需在Linux系统中把你的播放进程设为特定类别即可获得控制精度提升,和CPU延迟降低。而xenomai的软件实现、和TI pru的硬件实现都需要播放器和DAC遵循特定API——这就导致了PPT中xenomai超低的延迟和本站烧友lalekuku实测的巨大背离;类似的用了TI pru的Bricasti网桥能卖上万,使用同样方案的beaglebone black开发板巨烂无比的性能和回放效果——除非是硬件软件厂商自己遵循相关API开发自己的产品,否则用户在自己的自行车上安装劳斯莱斯的发动机是不会提高性能的。而常见的Roon/HQPlayer/MPD等等播放软件全都是面相通用硬件设计的,无法天然的享受这些API带来的低延迟。

CPU延迟优化到底能带来什么听感提升呢,像我在本站的所有帖子一样,不在讨论范畴之内。这里无责任引用Holo的说法:“所谓的延时低就好声音的说法,是基于射频噪声在时序上和音乐产生紧耦合后,降低对听感的影响”。好吧,其实我根本不知道他说的什么意思。本文接下来的章节介绍我所使用的降低延迟的方案,可能有些在之前的帖子里说过,为了保证完整性就再简单说一次小标题,具体命令可以看我别的帖子。需要说明,虽然其中一部分篇幅是网络延迟相关的,但却是以降低CPU延迟为首要目标,并非为了优化网络延迟本身。



作者: 中关村东路    时间: 2023-11-4 01:35
2. 硬件因素

这段本来是不想写的,但对硬件设备还没稳定下来的烧友可能有些价值。

2.1 第一条非CPU性能莫属。很尴尬吧,高性能CPU会带来更低的延迟,更流畅的软件体验,也可能引入干扰,同时供电和散热也不好处理。事实上有一些高端(贵)方案会搞Intel至强CPU或者AMD标压CPU。如果你能搞定干扰、供电和散热,上高性能CPU是有收益的。我就知道有高端烧友用的几万块的jcat线性ATX电源和标压CPU做网桥。我自己是低烧,目前用四核赛扬加PCIE-usb卡做naa,树莓派4b/cm4做roon客户端听着玩。AMD 5600x+nvidia rtx 4090做HQ。十代i3加96G内存缓存组zfs raid做roon core。几个网桥全部无风扇+线电。其他机器是开关电源+风扇自动启停。目前硬件的钱还集中在耳机解码耳放上。

2.2 除非性能有硬性要求,否则尽量使用单芯片设计的CPU。举个例子amd 7900x这种胶水的高端CPU,反而延迟高于7600x,这就至少并不适合作为网桥CPU了。

2.3 在绝大部分场景,关闭超线程(HT/SMT)能降低延迟。只有程序质量较低,系统负载较高的情况下适合打开超线程。

2.4 打开turbo boost,pbo,或者超频会降低延迟,当然,一些朋友包括我希望保持cpu主频固定且无风扇,就无法利用这项提升了。

2.5 选择尽量新的CPU。这条也是很无奈,很多老CPU bug多,打开mitigation会大幅降低性能,并提高延迟。同样在内核中不打补丁的情况下,老CPU风险却比新CPU大得多。



作者: 中关村东路    时间: 2023-11-4 01:35
3. 内核补丁

正好最近Linux内核主线升级到6.6分支,很大可能会是一个长期服务的LTS分支,我也把zfs NAS之外的其他系统都升级到了6.6。下面列的一些上游补丁还没升级的,暂时由我在我的Gentoo软件源维护。除非你也用Gentoo,否则你阅读本文时上游已经更新的代码建议直接使用原始链接,因为我水平有限,且肯定没在你的发行版上测试过。

3.1 rt patch

著名的rt patch【1】,具体的代码可在链接【2】下载。需要指出的是,kernel 6.6对应的rt patch在经典的Full Preempt基础上提出了改进:Automagic preemption mode with runtime tweaking support。经典的full preempt模式缺点——闲时系统负载较高,数据吞吐量较低——在新模式下都有改进。具体介绍可以在链接【2】中阅读。

非常有价值的是,经典full preempt模式下树莓派cm4 soc直出的dwc2 usb一直有bug,播放高码率DSD/PCM时会有卡顿,新模式解决了这个问题。略有遗憾,官方推出的rt patch【1,2】目前只支持x86系统下的automagic模式,也就是说树莓派的armhf和arm64都是不支持的,也不知道他们有没有计划推进。。。我把代码简单迁移了一下,开源在链接【3】中,目前(以及可预见的未来)只支持arm64。关于链接【3】,我在本站的帖子【4】中介绍过。我维护的树莓派automagic版内核只能说是just work for hifi,不支持gpu,不支持串口,不支持printk线程安全,当然这些东西网桥也确实用不上,我配置内核时候都关掉了。有编程基础的同学可以尝试一下更完整的,或者其他架构的支持,当然也可以等等上游。目前我在AMD HQPlayer专机和cm4 roon ready上用的automagic preempt,赛扬naa上和rpi4b roon ready上用的full preempt,roon core没用实时内核,用的是一套面向非实时流式数据优化的bmq调度器详见【4】。

【1】https://wiki.linuxfoundation.org/realtime/preempt_rt_versions
【2】https://cdn.kernel.org/pub/linux/kernel/projects/rt/6.6/
【3】https://github.com/zhjie/zhjie_gentoo_repo/tree/master/sys-kernel/raspberrypi-rt-sources
【4】http://erji.net/forum.php?mod=vi ... =2312699&extra=

3.2 BBR patch

Google的BBR patch【5】已经到了第三版,虽然是网络拥堵算法,但对于相对低性能的网桥而言,可以降低CPU负载。Gentoo用户可以直接用我维护的版本【3,4】,debian/ubuntu系用户可以使用【6】,archlinux系用户可以使用【7】,其他用户可参考官方【5】。我所有机器都打了bbr3补丁,不过如果你正用着一代或二代,不需要升级,意思意思得了。

【5】https://github.com/google/bbr/tree/v3
【6】https://xanmod.org/
【7】https://cachyos.org/

3.3 high-hz patch

CPU Timer frequency。古老的服务器或者性能极其低下的soc(再次,例如Beaglebone black)不需要也不能在毫秒这个数量级快速响应用户的请求,采用HZ_100即可;现代网络服务器一般设置为HZ_250;Hqplayer os上使用了所谓低延迟内核,设置为HZ_1000,更适合现代桌面系统和音频处理系统。如果你用的是debian/ubuntu,可以直接搜索lowlatency安装低延迟内核。但如果你有更高的要求,例如付费hifi系统audiolinux上支持HZ_1666,这就需要打些补丁了:Archlinux用户如果在用6.5或更老的内核可使用cachy os维护的内核【6】;如果你用的是6.6内核,目前只能用我维护的版本了,依然在【3,4】可以下载阅读。目前,我的Roon Core设置为HZ_250,HQPlayer和所有常用网桥都设置为HZ2000。其实我还有一套老mbp装Gentoo做roon core,beaglebone black做网桥的破系统寒暑假用,因为没有hq,就给core上的HZ1000,桥太弱上的HZ100。

3.4 kernel compiler patch

让内核编译按CPU支持的指令集优化,而不是路由器固件或通用发行版默认的二十多岁的AMD64/X86_64。其实这补丁早应该进主线内核了,圈内几乎人人都用的,甚至一些发行版把这玩意儿当成收费点了。其实很容易就用上了,有条件必选。

【8】https://github.com/graysky2/kernel_compiler_patch

3.5 cloudflare tcp patch

这是个神奇的patch【9】,能提高数据吞吐量,降低延迟,没仔细看他的代码,考虑到他家做这么大,我是信了的。Xanmod【6】也在维护。当然,一贯的,如果你是Gentoo用户可以直接用我的源【3,4】,都有。

【9】https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/


作者: 中关村东路    时间: 2023-11-4 01:36
4. 内核设置

很多优化设置可以在内核中,也可以在系统中,从效果上看两者几乎没有区别。付费系统GentooPlayer把很多优化放在内核,AudioLinux则把几乎所有优化都放在系统。我的方案是尽量放在内核中的,主要因为我一直用的系统是Gentoo(不是GentooPlayer,而是原生的那个),如果你用的系统编译内核不方便,建议按着这几个优化的项目挨个去Google,应该几乎都能找到不用编译内核的解决方案。

4.1 expert users

General setup  --->  Configure standard kernel features (expert users)  --->

先得选上这项,必须选这个才让选rt系统。选了之后点进去顺手删掉Enable PC-Speaker support。就是上古时代的电脑开机时候滴的那声的驱动,做的各种buggy,又没人真用,却人人都有的设备。

4.2 RT

General setup  --->  Preemption Model

需要尽量低延迟,机器性能强又不怕费电的选Fully Preemptible Kernel (Real-Time),差一级的选Automagic preemption mode with runtime tweaking support,或者中庸一些Preemptible Kernel (Low-Latency Desktop)。如果你的机器非常老或者总觉得卡,就选Server,配合后面的HZ_100立竿见影,变成柔和的卡。

4.3 Timers

General setup  --->  Timers subsystem  --->  Timer tick handling

选择Full dynticks system (tickless)。回头我们软件配置的时候要用到,

4.4 RCU

General setup  --->  RCU Subsystem  --->  Make expert-level adjustments to RCU configuration

下面除了force的几条之外挑挑拣拣能选上都选上。也是回头软件配置的时候要用到。

4.5 V3 optimization

Processor type and features  --->  Processor family

如果知道你的cpu,例如AMD Zen 3,就直接选,不知道就选Intel-Native optimizations autodetected by the compiler或者AMD-Native optimizations autodetected by the compiler。当然如果你不知道自己cpu型号但知道自己的cpu支持avx2也可以直接选v3,这适合交叉编译的情况。

4.5 关闭NUMA

Processor type and features  --->  NUMA Memory Allocation and Scheduler Support

关掉,这东西多核才有正提升。

4.6 HZ_2000

Processor type and features  --->  Timer Frequency

冲吧少年。树莓派做网桥是可以支撑HZ_2000的,HZ_1000也可以。Roon Core和NAS之类的机器建议适当降低。但是要知道一件事,更低的延迟总是以性能(吞吐量)降低为代价,如果你设置的太过火,播放的时候会卡到突然停掉,就降低一些。这是因为性能不足够高的情况下,太高的TF值会导致一个CPU时间之内任务都没做完。因此,上古老机器选HZ100吧。

4.7 关闭mitigation

Mitigations for speculative execution vulnerabilities

为了安全可以不关这一项。但最简单的避免出问题的办法是把机器藏起来,关掉或改掉没用的端口,禁用密码登录改用公钥。

4.8 performance governor

Power management and ACPI options  --->  CPU Frequency scaling  --->  Default CPUFreq governor

选择performance。

4.9 网络相关

Networking support  --->  Networking options  --->  TCP: advanced congestion control

选择BBR TCP和Default TCP congestion control (BBR)

Networking support  --->  Networking options  --->  QoS and/or fair queueing

选择Flow Queue Proportional Integral controller Enhanced和Allow override default queue discipline  --->  Default queuing discipline (Flow Queue Proportional Integral controller Enhanced)当然,只要你知道你在选什么,那么一些其他的算法也可以。


作者: 中关村东路    时间: 2023-11-4 01:44
5. 软件设置

这段是本文重点。关闭超线程,打开或关闭turbo boost,pbo等等设置可以在BIOS里设置,也可以在软件设置,这里就不介绍了。这主要写一些行之有效又很少看到人说的。下面的设置中,假定有四个cpu核心/线程,树莓派啊,j3455到现在的j6412赛扬,各种各样的amd/intel标压cpu之类的烂大街设备都满足。cpu0留给系统使用,cpu1给网卡,cpu2给解码,cpu3给naa或者roon raat。这样的好处,是每次执行一个任务的时候,如果是网卡有关的就直接找cpu1,cpu1也肯定正闲着。如果是解码有关的事都找cpu2,也正闲着。主程序就自己独占了cpu3,也没别人和他抢了(我个人不建议一台机器上同时开着naa和raat,抢DAC时候会print好些日志,强迫症忍不了)。这种原始又粗暴的方法可以有效降低音频应用的延迟。当然,如果你机器发热厉害,或者只有双核,也可以使用下面的方法,把一个核心隔离出来分配给naa/roon。

5.1 rt内核启动参数

确切的说,是在你当前的内核启动参数基础上加上这些东西。有些东西比如threadirqs不加其实也是可以的,写在这里是为了保持逻辑完整。我们的目的,是让系统除了cpu0之外的CPU(也就是cpu1-3)都留着不分配,刚启动时候所有程序都运行在cpu0上。如果你是尊敬的线程撕裂者用户,也可以只保留三个给音频,其他的都分配出去。

如果你用的是grub启动,需要修改/etc/default/grub,在原有GRUB_CMDLINE_LINUX_DEFAULT基础上加上:

  1. GRUB_CMDLINE_LINUX_DEFAULT="threadirqs skew_tick=1 rcu_nocb_poll rcu_nocbs=1-3 nohz=on nohz_full=1-3 kthread_cpus=0 irqaffinity=0 isolcpus=managed_irq,domain,1-3 intel_pstate=disable nosoftlockup tsc=nowatchdog"
复制代码

如果你用的是树莓派,这段东西要写在/boot/cmdline.txt。

5.2 修改音乐播放软件的优先级和程序类型

下面是我在Gentoo openrc网桥上roon ready启动脚本的一部分,意思是让这个程序运行在NICE=-19,RT_PRI=-96,分配给CPU3,也就是最后一个CPU。非Gentoo用户具体修改方法可参考我在本坛的帖子《Roon系统硬核安装笔记》【1】。

【1】http://erji.net/forum.php?mod=vi ... =2253401&extra=

  1. export SSD_NICELEVEL="-19"
  2. user="root:root"
  3. logfile="/tmp/roon.log"
  4. command="taskset"
  5. command_args="
  6.         -c 3 chrt -r 95 /opt/RoonReady/raat_app /etc/raat.conf > $logfile 2>&1
  7. "
复制代码


5.3 修改不同线程的优先级


  1. CHRT_LIST="xhci_hcd ksoftirqd ktimer ahci rtc acpi"

  2. chrt_process() {
  3.     PRI1=89
  4.     for NAME in ${CHRT_LIST}
  5.     do
  6.         PIDS=`ps -eLf | grep "${NAME}" | awk '{print $4}'`
  7.         for PID in ${PIDS}
  8.         do
  9.             if [[ ! -f /proc/${PID}/status ]] || chrt -p -f ${PRI1} ${PID}
  10.             then
  11.                 echo "chrt -p -f pid=${PID} prio=${PRI1}: OK."
  12.             else
  13.                 echo "chrt -p -f pid=${PID} prio=${PRI1}: FAILED."
  14.             fi
  15.         done
  16.         PRI1=$((${PRI1} - 5))
  17.     done
  18. }
  19. chrt_process
复制代码


上面代码中,CHRT_LIST里的字符串来自htop或者ps aux,执行一下这两个命令之一就明白了。其中第一项是你的解码对应的线程,一般系统上都用xhci_hcd(usb3驱动),如果你的主板不支持usb3,或者你不用usb解码/界面,可以不动或者改成你的设备对应的PID。非full preempt系统没有ktimer这条,不过其实不必理会,直接运行这段代码即可,已经考虑了兼容性。


5.4 分配解码和网卡的中断


  1. eth_cpu() {
  2.         NAME="eth"
  3.         echo "eth->cpu"
  4.     IDS=`cat /proc/interrupts | grep "${NAME}" | awk '{print $1}'`
  5.     for ID in ${IDS}
  6.     do
  7.         ID="${ID/:/}"
  8.                 echo ${ID}, 2
  9.         [[ ! -f /proc/irq/${ID}/smp_affinity ]] || echo "2" > /proc/irq/${ID}/smp_affinity
  10.     done
  11. }
  12. eth_cpu
复制代码

  1. usb_cpu() {
  2.     NAME="dwc2_hsotg"
  3.     echo "usb->cpu"
  4.     IDS=`cat /proc/interrupts | grep "${NAME}" | awk '{print $1}'`
  5.     for ID in ${IDS}
  6.     do
  7.         ID="${ID/:/}"
  8.         echo ${ID}, 4
  9.         [[ ! -f /proc/irq/${ID}/smp_affinity ]] || echo "4" > /proc/irq/${ID}/smp_affinity
  10.     done
  11. }
  12. usb_cpu
复制代码


上面NAME里的字符串来自/proc/interrupts,注意如果你用的是光纤网卡,那么eth需要改为对应的字符串;如果你用的不是holo red,那么dwc2_hsotg要改为你的usb驱动xhci_hcd,或者iis卡fe804000之类的。怎么识别出来呢,有个小技巧。如果你还没配置过cmdline.txt启动参数,cat /proc/interrupts的结果应该是如下面网图1这种乱七八糟到处都可能有数字的。



图1,普通系统的中断

如果你按我写的配置了内核,并修改了启动参数,那应该几乎所有行的数字都写在最左边,也就是cpu0下,如下图2所示。这时候你打开roon或者hq放点声音,前面的数字就会增加了。放音乐时候增加的那个就是要修改的网卡,解码器,或者硬盘。如图所示,ahci[0000:00:12.0]这行就是硬盘了,我们回头会做成内存系统,不必理会。eth0这行按名字就知道是网卡了,你在eth_cpu这填eth或者eth0。xhci_hcd有这么多,但可以看到只有 PCI-MSIX-0000:03:00.0 这个设备是激活状态,因为这是我的pcie-usb卡(买的带时钟的国产的就不推荐了),我就可以在NAME这填写。如果你觉得这还有好几个设备也被一起搜进去了,很尴尬啊,那可以把这行改为:


  1.         IDS=`cat /proc/interrupts | grep "${NAME}" | grep "0-edge" | awk '{print $1}'`
复制代码


这就只保留有数据的那个0-edge的通道了。



图2,隔离后刚启动的中断

补充一下,非IO-APIC硬件是不支持动态修改affinity的,这就只能通过内核启动参数限制在cpu0了。

【2】https://cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt

5.5 PCIE设备的优先级


  1. setpci -v -d *:* latency_timer=b0
  2. export PCI_ID=`lspci|grep TUSB73x0|awk '{print $1}'`
  3. setpci -v -s $PCI_ID latency_timer=ff
复制代码


前面说了我搞了个pcie-usb卡。所有pcie设备都会有个编号,lspci就看到了,还带英文介绍的,我的介绍里这张usb卡是TUSB73x0的,我就把这字符串填写在上面代码里。效果就是,让这张卡的延迟优先级设为ff,高于其他所有卡的b0。如果你有独立网卡或者USB卡,可以写在这。

5.6 内存系统


  1. process_dir() {
  2.     if [ $# == 1 ]; then
  3.         mount none -t tmpfs -o noatime /mnt/.ramdisk/$1
  4.         rsync -a /$1/ /mnt/.ramdisk/$1 --exclude modules --exclude src --exclude cache --exclude db --exclude firmware --exclude portage
  5.         mount -o bind /mnt/.ramdisk/$1/ /$1/
  6.     fi
  7. }

  8. sync && echo 3 > /proc/sys/vm/drop_caches
  9. umount /boot                2>/dev/null
  10. rm -r /mnt/.ramdisk         2>/dev/null

  11. mkdir -p /mnt/.ramdisk/{etc,opt,root,tmp,usr,var}

  12. for dir in etc opt root tmp usr var
  13. do
  14.     echo -e "/$dir ..."
  15.     process_dir $dir
  16. done

  17. sync && echo 3 > /proc/sys/vm/drop_caches
复制代码


之所以这里要折腾一下内存系统,主要是不想再设置ssd的中断了(其实是四个核心用完了...)。上面的脚本很容易看懂并迁移到你的系统上,只需修改mkdir一行和for一行。大约的意思就是,把硬盘根目录上的文件夹,都同步到tmpfs的内存里,之后再把tmpfs的文件夹bind回原来的硬盘文件夹下,这样想要读原文件夹时候就会访问内存而不是硬盘了。

5.7 看看效果吧

经过上面一通折腾,再放会儿音乐,cat /proc/interrupts看看效果,如下图3。



图3,优化后的中断

可以看到不会再增加ahci也就是硬盘的cpu0占用了,说明内存系统果然生效了。看到eth0在cpu0上的数据也不再涨了,从无到有的是cpu1这一列数据,这是因为前面执行了eth_cpu函数把网卡绑定到cpu1了。0-edge xhci_hcd的第一列数据也不变了,cpu2这一列增长了不少。至此我们就把桥的cpu分配好了。至于hq和roon core也可类似优化。




作者: 中关村东路    时间: 2023-11-4 01:44
6. 小结

本文缘起是看到一位烧友说起xenomai是真正的实时系统,为了避免其他人误会就想写点什么。正好这几天我的Gentoo源因为kernel 6.6发布而大升级,又玩上了最新的augomagic rt内核,就有了本文。其中大部分补丁和代码一些朋友们已经用过很久了,Roon官方论坛也有人使用,会给我提bug,这么多年了可以说是稳定的。也欢迎读者在帖子下留言批评指正。公司个人都可以直接使用我的代码牟利,完全开源免费,也不是gpl3协议,用着有什么问题也可以讨论,但之前有些找我做产品的就算了,不是程序员水平不够。


作者: 中关村东路    时间: 2023-11-4 01:44
打完收工
作者: kenxu1118    时间: 2023-11-4 02:13
太专业了点看着头晕,打了这么多字还是支持一下
作者: norman_lu    时间: 2023-11-4 09:43
本帖最后由 norman_lu 于 2023-11-4 09:50 编辑

我是Holo Red用户,并没有用官方的系统,自己装了gentoo linux,然后用了楼主提供的补丁自己编译了内核,来补充几句。(只适用于树莓派cm4)


OpenRC, runit and other script based systems and managers
           
systemd


作者: norman_lu    时间: 2023-11-4 10:21
延迟测试对比

1 低延迟内核
gentoo-rpi4 /usr/src # cyclictest  -l 10000 -m -Sp98 -i100 -d0                                                                                             
# /dev/cpu_dma_latency set to 0us                                                                                                                           
policy: fifo: loadavg: 0.08 0.33 0.17 2/108 7829                                                                                                            

T: 0 ( 7826) P:98 I:100 C:  10000 Min:      8 Act:    9 Avg:    9 Max:      60                                                                              
T: 1 ( 7827) P:98 I:100 C:   9936 Min:      8 Act:    9 Avg:    9 Max:      16                                                                              
T: 2 ( 7828) P:98 I:100 C:   9823 Min:      7 Act:    9 Avg:    8 Max:      14                                                                              
T: 3 ( 7829) P:98 I:100 C:   9691 Min:      9 Act:    9 Avg:    9 Max:      30



2 automagic内核 (做了内核隔离,所以只有三cpu的测试结果)
GentooRed /usr/src/linux # cyclictest  -l 10000 -m -Sp98 -i100 -d0                                                                                          
WARN: stat /dev/cpu_dma_latency failed: No such file or directory                                                                                          
policy: fifo: loadavg: 0.97 0.43 0.16 1/124 25456                                                                                                           

T: 0 (25454) P:98 I:100 C:  10000 Min:      4 Act:    4 Avg:    4 Max:      26                                                                              
T: 1 (25455) P:98 I:100 C:   9942 Min:      4 Act:    5 Avg:    5 Max:      61                                                                              
T: 2 (25456) P:98 I:100 C:   9839 Min:      4 Act:    5 Avg:    4 Max:      27



作者: 中关村东路    时间: 2023-11-4 12:19
norman_lu 发表于 2023-11-4 09:43
我是Holo Red用户,并没有用官方的系统,自己装了gentoo linux,然后用了楼主提供的补丁自己编译了内核,来 ...

链接里我之前的帖子里讲了如何使用clang lto,这里就没说
作者: Devastat0r    时间: 2023-11-4 15:51
进来膜拜一下,懒+笨的用户比如我还是准备3台X86机器,一台刷daphile,一台刷HQPE OS,一台刷NAA,全部官方镜像最方便了
作者: 中关村东路    时间: 2023-11-4 18:05
Devastat0r 发表于 2023-11-4 15:51
进来膜拜一下,懒+笨的用户比如我还是准备3台X86机器,一台刷daphile,一台刷HQPE OS,一台刷NAA,全部官方 ...

hq官方镜像确实不错。我用了好久
作者: 吧哦哦of    时间: 2023-11-4 18:57
养肥了慢慢看
作者: lalekuku    时间: 2023-11-4 20:42
本帖最后由 lalekuku 于 2023-11-4 22:03 编辑

最喜欢看这种技术贴,太牛了。好在一直跟大佬学习,基本都能看懂,获益匪浅,我自己的rt内核基本就是参照大佬的思路优化的,效果很好,在优化脚本上也加了一些自己的想法。
请教一下,上面的树莓4平均延迟能低到4,属实厉害。这是运行在多高频率下?
我用一块rk3328的板子,性能估计不到树莓4的一半,1G内存,锁定频率在1392Mhz,性能模式,使用HZ_1000,平均延迟能到5或6,是不是也还凑合?
cyclictest  -l 10000 -m -Sp98 -i100 -d0
WARN: stat /dev/cpu_dma_latency failed: No such file or directory
policy: fifo: loadavg: 0.19 0.11 0.09 1/121 1871

T: 0 ( 1870) P:98 I:100 C:  10000 Min:      5 Act:    6 Avg:    5 Max:      31
T: 1 ( 1871) P:98 I:100 C:   9899 Min:      5 Act:    9 Avg:    6 Max:      25

在另一块rk3399板子上延迟如下,2g内存,内核使用HZ_1000,处理器4个小核1.416GHz+2个大核1.8GHz:
cyclictest  -l 10000 -m -Sp98 -i100 -d0
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.65 0.48 0.17 1/191 2147

T: 0 ( 2142) P:98 I:100 C:  10000 Min:      5 Act:    7 Avg:    7 Max:      15
T: 1 ( 2143) P:98 I:100 C:   9958 Min:      5 Act:    6 Avg:    6 Max:      24
T: 2 ( 2144) P:98 I:100 C:   9880 Min:      5 Act:   10 Avg:    7 Max:      13
T: 3 ( 2145) P:98 I:100 C:   9801 Min:      5 Act:    7 Avg:    6 Max:      14
T: 4 ( 2146) P:98 I:100 C:   9717 Min:      3 Act:    3 Avg:    3 Max:      14
T: 5 ( 2147) P:98 I:100 C:   9640 Min:      3 Act:    6 Avg:    3 Max:      12

还有些个人想法借贵贴一起探讨:
1、关于中断,用黑名单可以屏蔽很多无用的设备,进而减少中断,但要小心,别把有用的设备屏蔽掉,否则可能无法启动系统;要想彻底点,还可以精简设备树,禁用无用设备(比如各类显示设备、板载声卡等等);更彻底点,直接在内核编译设置里去掉驱动(编译设置这个不知道我理解的对不对)。
2、HZ_1666用过,但声音在我系统上听起来不是太习惯,似乎有点硬,估计是因系统而异,不知大佬用这个1666有啥不一样的感觉?
3、bbr3在xanmod里似乎是直接替换了v2和v1,编译设置时没有v1和v2的选项,只有一个bbr,不知是不是这样?
4、给板子插了usb网卡,以扩充网口,用ip a命令查看网卡信息如下:
自带网卡:eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000
USB网卡:eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_pie master br0 state UP group default qlen 1000

可以看到自带网卡没有打开fq_pie ,而usb网卡却打卡了fq_pie,这是怎么回事?我在sysctl.conf里是设置了fq_pie参数的,为什么只有usb网卡生效?(请忽略里面的state DOWN,在UP时也是一样的信息
5、大佬能不能抽空讲一讲怎么精简系统?现在用的dietpi其实已经比较精简了,但感觉还是有冗余,后台服务有些也不敢随便动。

6、xanmod啥时候能把rt内核更新到6.5以上啊?


作者: zhuyunbin    时间: 2023-11-4 20:48
太专业了
作者: johnarcam    时间: 2023-11-4 22:21
先收藏了,
作者: 中关村东路    时间: 2023-11-4 23:25
吧哦哦of 发表于 2023-11-4 18:57
养肥了慢慢看

看吧,我一般不撘楼,再有新东西会发新帖

作者: 中关村东路    时间: 2023-11-4 23:51
lalekuku 发表于 2023-11-4 20:42
最喜欢看这种技术贴,太牛了。好在一直跟大佬学习,基本都能看懂,获益匪浅,我自己的rt内核基本就是参照大 ...

挺多的,简单回答下吧


1. 3328跑分其实挺强的,和树莓派比单核大约是1 : 1.5吧。3399单核多核跑分都比树莓派超频后更强一些。但是延迟和性能并不是完全正比的,和架构有关,像arm就明显不如x86,在相同cpu性能的情况下。不过话说回来,延迟到底有什么用,这玩意儿没法说的。手里有多少设备,挨个试试哪个听着好听就行。听不出来的话,要么哪个方便哪个来,要么哪个技术先进选哪个都行。。。

2. 设备树和驱动程序的关系这个,每种设备都是不一样的。比如x86系统一般不用设备树维护,而用udev的多,树莓派我也用的udev维护。我估计前面Norman的Gentoo也是用udev的。


3. 精简系统其实并没什么实际意义,更多的是强迫症行为。因为多数文件启动之后也就不再读了,实在不行都放内存里了速度也够了,事实上我这测试了内存缓存+nvme甚至都不一定干的过nvme ext4文件系统直接读,如果nvme硬盘性能足够强,就完全没精简的必要了。

4. xanmod是补丁集合,技术实力有限,而且求稳的,高版本rt可能要很久了。

作者: lalekuku    时间: 2023-11-5 00:11
中关村东路 发表于 2023-11-4 23:51
挺多的,简单回答下吧

感谢详细解答。
今天发现3328板子上usb2.0接口dwc2产生的中断非常多,即使不做什么事,开机后静静的在那放着,也会产生很多中断,比u3口多好几个数量级,没几分钟就能达到几百万次中断。
这可能是什么原因呢?该怎么解决比较好?

作者: 中关村东路    时间: 2023-11-5 00:36
lalekuku 发表于 2023-11-5 00:11
感谢详细解答。
今天发现3328板子上usb2.0接口dwc2产生的中断非常多,即使不做什么事,开机后静静的在那 ...

关了驱动……

作者: nuvola    时间: 2023-11-5 00:42
有点疑惑,减少延迟能提高播放音质吗?我的理解如果是音频制作。这个操作延迟是很重要。但从欣赏音乐来说,如果这个延迟是指按下播放键后到听到音乐的延迟。那似乎没什么意义啊。
作者: 中关村东路    时间: 2023-11-5 02:46
nuvola 发表于 2023-11-5 00:42
有点疑惑,减少延迟能提高播放音质吗?我的理解如果是音频制作。这个操作延迟是很重要。但从欣赏音乐来说, ...

第一段就解释这个了,你说的这个不影响音质,只有cpu延迟影响

作者: simmconn    时间: 2023-11-5 06:19
看来看去搞这些劳什子玩艺,还是对音质没影响啊。要说低延时,搞个51单片机跑bare metal,守着DAC,需要一个sample就送一个,岂不是延时最低?
现代的SoC里面都是scater gathering的DMA,CPU只管配好了DMA描述符,后面数据传输都是自动的,不论网口、USB还是I2S。接口buffer快缺数据了,DMA就从内存里面存/取几k的数据给他。
CPU大部分时间都躺平歇着,延迟不延迟的木有影响吧。
作者: lalekuku    时间: 2023-11-5 07:38
中关村东路 发表于 2023-11-5 00:36
关了驱动……

好的,我在这个方向上挖一挖

作者: lalekuku    时间: 2023-11-5 07:49
nuvola 发表于 2023-11-5 00:42
有点疑惑,减少延迟能提高播放音质吗?我的理解如果是音频制作。这个操作延迟是很重要。但从欣赏音乐来说, ...

你说的这个是操作响应延迟,不是音频流播放延迟,完全不是一个概念。后者还涉及到一个时基误差问题,有时候会显著影响听感。

可以简单理解为,低延迟能让数据流推送的更绵密,进而改善声音

作者: 中关村东路    时间: 2023-11-5 11:26
simmconn 发表于 2023-11-5 06:19
看来看去搞这些劳什子玩艺,还是对音质没影响啊。要说低延时,搞个51单片机跑bare metal,守着DAC,需要一 ...

你说的对啊,单片机确实延迟低,cd转盘就这么搞的。为什么串流的网桥不能这么做呢?因为需要跑标准Linux系统才能运行roon/naa的软件

作者: nuvola    时间: 2023-11-5 11:40
lalekuku 发表于 2023-11-5 07:49
你说的这个是操作响应延迟,不是音频流播放延迟,完全不是一个概念。后者还涉及到一个时基误差问题,有时 ...

那速度快的cpu是不是比较好?

作者: lalekuku    时间: 2023-11-5 11:48
nuvola 发表于 2023-11-5 11:40
那速度快的cpu是不是比较好?

没错。但还有其他影响因素,比如各种类型的干扰,有硬件层面的,也有软件层面的,说起来就比较复杂了,不是一种因素能决定的。
不论是各种隔离也好、优先级调整也好,等等,都是为了让实时进程能够更顺畅的工作。
贴主大佬科普的已经很全面了。

总之,优化好的系统相比无优化的系统,听感是变化明显的,后者只能算是听个响吧。


作者: 中关村东路    时间: 2023-11-5 11:50
本帖最后由 中关村东路 于 2023-11-5 12:05 编辑
nuvola 发表于 2023-11-5 11:40
那速度快的cpu是不是比较好?

能控制好干扰和供电的情况下是这样啊,我帖子里写了,高端数播很多都是标压cpu,还有用高缓存的amd甚至志强的


但事实是,性能特别好的cpu,干扰和供电并不容易做好。一般玩家和中低端厂商可能用arm+良好供电+适合的软件,反而更容易一些

作者: atioox    时间: 2023-11-5 13:10
有没种可能,只要系统性够强,延时什么都是小问题
和上古单片机比起来,现代的软件系统简直太臃肿,但不妨碍大力出奇迹
作者: 中关村东路    时间: 2023-11-5 13:43
atioox 发表于 2023-11-5 13:10
有没种可能,只要系统性够强,延时什么都是小问题
和上古单片机比起来,现代的软件系统简直太臃肿,但不妨 ...

你说的对啊,但问题是系统足够强会导致太高的干扰,难处理的散热和成本更高的线性供电。这就是一个trade off
其实数播网播都是玩玩而已,要想正常的成本音质好,那肯定是CD的

作者: lalekuku    时间: 2023-11-8 09:05
今天看到另一个帖子里有这种说法:“超頻後亦只能夠把 piCorePlayer 的 kernel timer frequency 調高到 264.6kHz,就是只有 44.1 的六倍”
大佬是否了解这个kernel timer frequency参数?它跟linux内核编译时的CPU Timer frequency是什么关系?二者差了好几个数量级
帖子链接:http://www.erji.net/forum.php?mo ... 16&pid=35466738
作者: 中关村东路    时间: 2023-11-8 14:57
lalekuku 发表于 2023-11-8 09:05
今天看到另一个帖子里有这种说法:“超頻後亦只能夠把 piCorePlayer 的 kernel timer frequency 調高到 264 ...

这位说的看看就得了,属于科学神学的..

作者: lalekuku    时间: 2023-11-8 16:04
中关村东路 发表于 2023-11-8 14:57
这位说的看看就得了,属于科学神学的..

哈哈。我确实没太看懂

作者: vvxonp    时间: 2023-11-8 16:42
顶一个,感谢技术大佬的分享
作者: 中关村东路    时间: 2023-11-8 21:39
vvxonp 发表于 2023-11-8 16:42
顶一个,感谢技术大佬的分享



作者: 中关村东路    时间: 2023-12-16 20:58
本帖最后由 中关村东路 于 2023-12-16 21:36 编辑

补充三组数据,图1是我树莓派4(cm)上的,延迟2/3/2/22;图2是audiolinux在树莓派5下超频到2800的数据2/3/2/10(多组数据取最优);图3是m1p的数据,作为一台普通或者高性能电脑的数据,比优化过的延迟差距是很大的。这么看的话,

1. 树莓派5可能未必是一个好的选择了,一方面性能可能提升有限,另一方面引入南桥芯片管理包括usb、网卡等等在内的“低速设备”


2. 当然了,如图2 audiolinux的说法,他的树莓派4b延迟是树莓派5的4-5倍,那就是8/12/8/40……如果用我的配置,树莓派5可能也会是个不错的选择


3. 最终用哪个还是要靠听感的,优化延迟就是随便玩玩


图1,我的配置下树莓派4(cm)延迟测试,2/3/2/22


图2,audiolinux树莓派5延迟测试,2/3/2/10



图3,看看正常数据是什么样的,apple silicon来被吊打




作者: lalekuku    时间: 2023-12-20 16:18
中关村东路 发表于 2023-12-16 20:58
补充三组数据,图1是我树莓派4(cm)上的,延迟2/3/2/22;图2是audiolinux在树莓派5下超频到2800的数据2/3/2/ ...

强!不知哪里能下到其他板子可以编译使用的6.6.X RT内核源码?

作者: 中关村东路    时间: 2023-12-20 17:35
lalekuku 发表于 2023-12-20 16:18
强!不知哪里能下到其他板子可以编译使用的6.6.X RT内核源码?

应该可以吧,我没用过别的板子。不过这数据并不全是因为实时内核,纯靠RCU可以达到比这稍差一点的延迟。配置文件都在我的安装源里
作者: lalekuku    时间: 2023-12-23 23:11
中关村东路 发表于 2023-12-20 17:35
应该可以吧,我没用过别的板子。不过这数据并不全是因为实时内核,纯靠RCU可以达到比这稍差一点的延迟。 ...

好的,

作者: linang    时间: 2023-12-25 16:24
楼主你好,我主板是双网口,安装arch linux ,能不能实现hqplayer输出独占或优先使用一个网口

作者: 中关村东路    时间: 2023-12-25 17:32
linang 发表于 2023-12-25 16:24
楼主你好,我主板是双网口,安装arch linux ,能不能实现hqplayer输出独占或优先使用一个网口

不如直接拔掉另外一根网线……

作者: 中关村东路    时间: 2023-12-25 22:25
linang 发表于 2023-12-25 16:24
楼主你好,我主板是双网口,安装arch linux ,能不能实现hqplayer输出独占或优先使用一个网口

kidding,archlinux用的systemd,可以实现这个功能,改一下hqplayerd的systemd文件应该就可以,我没有archlinux无法测试了。参考【1】,搜索 RestrictNetworkInterfaces

  1. sudo systemd-run -t -p RestrictNetworkInterfaces=enp0s8 ping 8.8.8.8
复制代码


【1】https://kinvolk.io/blog/2021/04/extending-systemd-security-features-with-ebpf/

作者: atioox    时间: 2023-12-26 00:22
音乐回放而言,时延平稳比时延低更有意义
当然,现实是,更多的设备只是模拟输出没做好,而不是什么时钟jitter,处理延迟影响了听感

作者: 中关村东路    时间: 2023-12-26 01:21
atioox 发表于 2023-12-26 00:22
音乐回放而言,时延平稳比时延低更有意义
当然,现实是,更多的设备只是模拟输出没做好,而不是什么时钟ji ...

嗯,我在绿檀所有帖子都不讨论听感,只说一个目标如何实现。不过如果你观察一下就会发现,延迟低和延迟的方差低(因为所有延迟都在一个很低的水平上)基本是正相关的

作者: lalekuku    时间: 2023-12-26 15:29
atioox 发表于 2023-12-26 00:22
音乐回放而言,时延平稳比时延低更有意义
当然,现实是,更多的设备只是模拟输出没做好,而不是什么时钟ji ...

你似乎把播放时延跟实时系统的内部处理延迟搞混了

作者: linang    时间: 2023-12-26 23:03
中关村东路 发表于 2023-12-25 22:25
kidding,archlinux用的systemd,可以实现这个功能,改一下hqplayerd的systemd文件应该就可以,我没有arc ...

hqplayered输出DSD512数据时,达到500MB,网线要输出又输入会造成拥堵,这时有必要让hq网络输出子进程独占一个网口是有必要的,对吗

作者: 中关村东路    时间: 2023-12-26 23:14
linang 发表于 2023-12-26 23:03
hqplayered输出DSD512数据时,达到500MB,网线要输出又输入会造成拥堵,这时有必要让hq网络输出子进程独 ...

算错了吧,印象中dsd512应该是和100M网卡一个数量级的。我有时候升dsd1024,有时候升dsd512,树莓派的千兆网卡就可以搞定

作者: linang    时间: 2023-12-26 23:21
中关村东路 发表于 2023-12-26 23:14
算错了吧,印象中dsd512应该是和100M网卡一个数量级的。我有时候升dsd1024,有时候升dsd512,树莓派的千 ...

我也觉得没哪么大,可能想尝试下吧,数据输出时不被中断和干扰是不是会更好些

作者: 中关村东路    时间: 2023-12-27 02:23
linang 发表于 2023-12-26 23:21
我也觉得没哪么大,可能想尝试下吧,数据输出时不被中断和干扰是不是会更好些

你如果想折腾一下,建议搞一下cpu隔离,好不好听我不知道,确实是不被干扰,性能也是有提升的尤其是responsiveness。举个例子,树莓派4b/cm4网桥有四个核,一个给乱七八糟的东西"housekeeper",一个给roon/naa,一个给usb解码器,一个给网卡。隔离之后网卡就不需要和其他线程进程抢cpu时间了。有更多核心也可以类似利用,我的roon core的八核,四个核心加64G内存给了zfs,另外四个核心和32G内存给roon core。
可参考我在本站的帖子【1】"Roon系统硬核安装笔记",先看目录直接找想要的段落即可。也可以参考ubuntu的手册【2】,opensuse的手册【3】,方案都是类似的,并不必须是实时内核才能用。
【1】http://erji.net/forum.php?mod=viewthread&tid=2253401
【2】https://ubuntu.com/blog/real-time-kernel-tuning
【3】https://www.suse.com/c/cpu-isolation-introduction-part-1/

作者: MusesAudio    时间: 2023-12-27 11:59
楼主技术NB
作者: clark8888    时间: 2024-1-15 12:36
实时 Linux 内核音质会更好吗? - invalid s的回答 - 知乎
https://www.zhihu.com/question/530950907/answer/3360679626
作者: 中关村东路    时间: 2024-1-15 15:27
本帖最后由 中关村东路 于 2024-1-15 15:31 编辑
clark8888 发表于 2024-1-15 12:36
实时 Linux 内核音质会更好吗? - invalid s的回答 - 知乎
https://www.zhihu.com/question/530950907/answ ...

首先呢,我所有的帖子都不说音质,只讨论技术问题。其次,你发个这种低智网站的低级程序员发的帖子想说明什么……但凡你稍微读懂了我的原贴也不会把cpu延迟和延迟联系当成一个东西,如果没读懂就不要来污染

作者: leonjo    时间: 2024-1-15 15:34
lz有考虑过用RTOS来试试么。比如QNX
作者: 中关村东路    时间: 2024-1-15 15:49
leonjo 发表于 2024-1-15 15:34
lz有考虑过用RTOS来试试么。比如QNX

主要还是hqplayer naa没提供RTOS的版本吧

作者: leonjo    时间: 2024-1-15 16:08
中关村东路 发表于 2024-1-15 15:49
主要还是hqplayer naa没提供RTOS的版本吧

这个确实,RTOS很多软件都没是硬伤。

作者: xbt123ufo    时间: 2024-2-26 13:23
按照楼主的方法,我给我的Chromebook,编译了实时内核,开启Automagic模式,打了cpu优化补丁,另外简单修改了一些选项,rootfs分区用void linux官网提供的rootfs。相比没有优化的通用内核,感觉音乐更有节拍感,身体打节拍更带劲了,不知道是不是脑放。
作者: xbt123ufo    时间: 2024-2-26 13:29
随便优化了一下Chromebook,延迟测试的数据就比audiolinux的树莓派5的数据低了
作者: 中关村东路    时间: 2024-2-26 14:21
xbt123ufo 发表于 2024-2-26 13:29
随便优化了一下Chromebook,延迟测试的数据就比audiolinux的树莓派5的数据低了

恭喜恭喜

作者: 中关村东路    时间: 2024-6-5 21:40
中关村东路 发表于 2023-12-16 20:58
补充三组数据,图1是我树莓派4(cm)上的,延迟2/3/2/22;图2是audiolinux在树莓派5下超频到2800的数据2/3/2/ ...


树莓派5延迟,比al的低多了...

作者: arunayang    时间: 2024-11-11 21:15
感谢楼主发这么好的技术贴,等有时间自己编译个rt内核玩玩。




欢迎光临 耳机网-耳机大家坛 (http://bbs.erji.net/) Powered by Discuz! X3.2