wxwxwx0 发表于 2024-11-17 12:35
http://erji.net/forum.php?mod=viewthread&tid=2347804

主要是第四节，梳理了一下为什么：DAC一 ...

从USB界面这个环节来看，软件若是要影响音质，那么有三种情况，一种是没有保证bit-perfect，这个不讨论，另外一个软件的差异造成的电磁干扰的差异，这个也不讨论，最后一个是jitter。
当你认为USB驱动发送URB的jitter会影响USB界面通过CPLD或者FPGA用界面本身的时钟生成的新的I2S信号的Jitter的时候，那是不是也可以认为，Apple Music服务器的网络Jitter，会影响播放器的系统内核发送URB的Jitter？

其实操作系统内核发送UBR的速率以及两个UBR之间的间隔(Jitter)是相当不稳定的，若以音频的要求来看，Jitter是极大，有时候会达到毫秒级。这种不稳定的音频数据在USB界面中会先被暂时存入一个Buffer中，然后会有一个CPLD或者FPGA通过自身的硬件时钟驱动，从这个Buffer中获取音频数据并以I2S的方式输出，这种机制并不是传统意义上的锁相环，因为有Buffer的存在，不需要根据输入信号的频率来锁输出信号的时钟，另外也需要注意，USB界面，输入信号的时钟是USB的时钟，输出信号的时钟是I2S的时钟，这完全是两个东西，锁相锁什么？。这个I2S信号的Jitter，和USB线缆中传递的数据的Jiiter又有什么关系呢？自然是没有关系的，这就好比说USB输出的Jitter，和网络输入的Jitter无关联一样，都不是一个协议时钟也做了隔离，它怎么产生关系呢？而且因为缓存和Feedbacck机制（后面会说）的存在，也不存在所谓的发送端时钟和USB界面时钟的差异会导致数据要填0或者因为缓存满了会被切掉数据的可能。

USB音频输出，要保证USB界面的Buffer不会Under-run也不会over-run是由一套feedback的机制来实现的，发送端会定期的（一秒钟N次）发起feedback查询请求，界面会根据自己Buffer的情况来反馈出一个下一刻的合适的速率，然后发送端会调整发送的速率保证USB界面的Buffer不会产生under-run和over-run。使用正确的USB线缆，加上正确的USB音频驱动，是很容易保证USB界面的缓冲区处于一个比较平衡的水线的。

USB界面的Buffer处理机制和I2S Buffer & ReClock不一样，老外有一种方案（I2S Buffer & ReClock）是在I2S路径增加一个硬件的buffer再加上重新生成时钟来输出新的I2S数据，I2S是单向数据流，没有反馈机制，所以能做的就是大缓存，加上歌曲间隔的时候根据缓存的情况是否补静音帧来实现bit-perfect的reclock。这种I2S Buffer & Reclock，也不是通过所谓的锁相环来实现的。

最后，ASRC的机制，ESS有篇专利说明，和你想像的缺数据要补点也是两回事。A是异步，异步了就不会缺数据，ESS的ASRC是为了解决非整数倍的SRC带来的问题，而且它不是简单的前一个点后一个点简单做个平滑那么简单，ASRC好不好听和这个机制也没有关系。具体的可以看ESS的专利文档，我记得我以前回帖的时候也大致的解释过ESS的这个专利，有兴趣可以翻来看看。

对比了楼主的接法和本帖另一个网友的设置方法，实在是听不出有什么区别

yukeelun 发表于 2024-11-17 12:21
請給你長文的連

http://erji.net/forum.php?mod=viewthread&tid=2347804

主要是第四节，梳理了一下为什么：DAC一方面很难隔离前端软件的影响，另一方面隔离了也不见得是好事

多謝

wxwxwx0 发表于 2024-11-17 11:19
... any audio device parameters don't effect on sound quality as long as you use bit perfect playbac ...

請給你長文的連

... any audio device parameters don't effect on sound quality as long as you use bit perfect playback and keep the parameters sensible so that they don't cause any buffer under-runs

这正是关于数字音频 长久以来最大的误区，因为这个buffer（空/满的情况）最终会影响时钟的稳定性。具体可以参考我之前发长文

转了好多弯子，现在的系统是树莓派安装volumio+roon bridge，一个小主机装rt达菲，一个小主机装archLinux-rt内核，笔记本foobar2000。三台设备都可以推树莓派，随意切换，只是不能同时两台设备播放。
感觉roon好像加了混音一样，听人声非常好听。达菲好一些，听人声也很好，听乐器，达菲更清晰。foobar2000就偏冷。

达菲官网有rt内核版的最新版的，比普通版的一耳朵提升，完全可以媲美roon。不过还是最好玩双机，或者达菲+树莓派。

wg5100 发表于 2024-11-17 10:51
安装达菲的电脑usb接口有2.0和3.0的，用那种好呢，好像没人说过这种问题

试试，理论上是2.0。

安装达菲的电脑usb接口有2.0和3.0的，用那种好呢，好像没人说过这种问题

xxbin1911 发表于 2024-11-15 23:00
先说达菲
达菲基本上就是早期的MIUI那样的东西，就是国产安卓手机早期的安卓皮肤。安卓皮肤不管怎么做， ...

前半篇我还是看懂了的，后半篇有点吃力。

对于“搞技术的人都说了没区别，而有些人非要分个所以然”这件事，我只能说我还是给我们这种外行但热爱实践的人留了一扇窗户——毕竟，有人连网线的方向都听出了区别（我感觉我就有）；假如真的有，您想想，网线的设计者会不会觉得匪夷所思？

总体来说感谢您的详细解答。我还得慢慢学习。

Victor_Derbobo 发表于 2024-11-15 21:44
感谢分享。我大致了解您说的内容了。您介绍的内容，我认为我是能理解的。

我其实一直准备有空直接去学 ...

先说达菲
达菲基本上就是早期的MIUI那样的东西，就是国产安卓手机早期的安卓皮肤。安卓皮肤不管怎么做，它的底层一定会是安卓，并且也受限于安卓，除非像华为，做个纯血鸿蒙。
LMS和Squeezelite就那么些参数可以改，达菲玩出花来，也就是那么点东西，UI上的一些设置选项，也只是让使用者觉得用起来舒服或者能更多的开脑放而已。

音频优化并不仅仅是对Linux是否熟悉的问题，而是要对各种播放软件以及音频输出的底层软硬件比较熟悉才可能有的放矢。我举个例子，Squeezlite有两个Buffer大家都比较熟悉的，Stream Buffer，Output Buffer，我在前面的帖子有时候会加上Decode Buffer，那种是在有DSP的情况才有的。我们挑简单的模式来说，就Stream Buffer+Output Buffer这种情况。
Stream Buffer存放从网络或者文件获取的原始音频数据，Output Buffer存放解码（FLAC->PCM）之后的待输出的音频数据。另外还有个声卡驱动层面的Buffer，那个是操作系统级别的，这里先忽略。
当使用比较大的Stream Buffer和Output Bufffer会发生什么事情呢？如果这两个Buffer足够大，那么在几秒内（取决于你的网络速度），Stream Buffer就存放了将要解码的这个音频的所有数据，之后网络线程就会退出，然后再过几秒钟，Decode线程也就能够把这些数据全部解码并存放到Output Buffer中，接下来，Decode线程也不做任何其他工作，处于类似休眠的状态。
也就是说，当你的Buffer足够大的时候，在歌曲的后半段，根本就没有网络处理和解码这回事，Squeezelite只会从Output Buffer中读取数据并填入ASLA声卡的缓冲区来播放。

这是在Squeezelite播放时会发生的事情，你能听出来什么时候网络线程停止工作了么？能听出来什么时候Decode线程休眠了么？你能听出来在一首歌的快结束的时候有什么不一样么？（Gapless的回放，在歌曲末尾，播放器会做一些其他事情，我不说，可能一般人也不知道内部的工作原理）
如果你能听出来这些差别，那么做一些软件上的优化是有意义的，如果你听不出来这些差别，那么解码线程在哪台机器上以及它工作与否，又有什么差别呢？
再则，当Squeezelite将音频数据填入内核的ALSA缓冲区之后，又会发生什么？这些数据又如何变成USB DAC所需要的URB（USB Reuqest Block），Squeezelite填入ALSA缓冲区的速度和块大小和URB又是怎么个关系？Squeezelite通过USB发送的音频数据（URB）到了USB界面又会发生什么？USB界面中的XMOS或者ARM又是如何处理这些数据的？USB界面中的CPLD或者FPGA又是干嘛用的？USB界面输出的I2S信号的Jitter和什么有关系？播放器的哪些设置会影响到USB界面的I2S信号输出？又是怎么影响的？种种这些问题如果没有去思考和了解，说不好听点也只能是盲人摸象，能弄出好声音那就是撞大运了。

当这些问题都不能了解背后的原理的时候，却认为达菲的作者是因为不够了解才会说出建议换个最好的DAC那种话来，那也只是自己的一厢情愿了。搞技术的，特别是能做出达菲这样的东西的，他不会是一个随便的人，他也不可能把一段他现在觉得有问题的话一直挂在网上的。似乎玩HIFI的都不太乐意听这些音频播放软件的作者的话，比如Foobar的作者说，Realtime对于回放基本无意义，只要能保证缓冲区不Under-run，实时和非实时内核，没差别。有谁会听呢？

再来是NAA
NAA只是一个网络到音频输出的异步FIFO转换，它不负责任何转码和DSP处理，它只会把已经解码好的音频数据用音频驱动所需要的方式异步输出。解码和DSP处理都是在HQ Player。HQ Player+NAA的架构与LMS+Squeezelite的架构是不太一样的，这基本上代表了两种典型音频回放架构。

Network audio is especially useful to give freedom from cables when player is run on a tablet or other wireless device.

Processing is performed by the player application and the processed data is then asynchronously streamed over network to a very lightweight network audio adapter interfacing to the DAC. Asynchronous FIFO provides maximum isolation between processing and audio reproduction.

至于我的系统，可能对大家没有啥参考价值，我用NAS+LMS，播放器用Squeezelite（树莓派或MAC MINI），偶尔也用自己写的播放器（Linux版本或Android版本，还不够稳定）。

xxbin1911 发表于 2024-11-15 18:37
论坛发帖只是为了分享一下信息，而不是要争个谁输谁赢。

我了解的信息是达菲是从git库拉的代码自己构 ...

最后一个问题：

您现在还用安装linux系统的主机作网桥吗？具体用的什么软件？或者能否分享一下您现在的整个前端系统？

xxbin1911 发表于 2024-11-15 18:37
论坛发帖只是为了分享一下信息，而不是要争个谁输谁赢。

我了解的信息是达菲是从git库拉的代码自己构 ...

哈哈达菲作者那个Q&A就是一段正确的废话。

他自己设计达菲的时候，可能都不知道“串串香”的道理。

xxbin1911 发表于 2024-11-15 18:37
论坛发帖只是为了分享一下信息，而不是要争个谁输谁赢。

我了解的信息是达菲是从git库拉的代码自己构 ...

感谢分享。我大致了解您说的内容了。您介绍的内容，我认为我是能理解的。

我其实一直准备有空直接去学linux来着。因为不仅从达菲，您应该也有了解到，市面上n多收费的音乐平台，都是基于linux开发的。达菲系统就仅仅是对小白来说，一定程度上够用且免费而已。如果掌握了linux对音频回放的优化知识，也不用拘泥于某个回放软件的功能多多少少了。

不过我还是蛮好奇达菲的作者为什么要在那个“解码”选项上这样去表述，如果按您的逻辑来说，他应该换更合适的表达才对。另外一个，我和论坛里不少人也体验到，那个选项选player和media server，听感差异不小呢。再者，我比较好奇，如果“但是无论怎么设置，squeezelite依然会跑stream/decode/output这几个流程，这可以通过查看squeezelite的线程来确定”，那它提供这个选项到底带来了什么区别？

Anyway，如果您有了解到什么新的信息，还请发文分享一下咯。再次感谢。

PS：那论坛里同样比较流行的roon server + HQPlayer embedded + NAA的串流模式，解码地点应该是在哪个环节您有了解吗？谢谢。

非常好，学习了

从标题来看，就玩错了！

Victor_Derbobo 发表于 2024-11-15 15:37
不敢苟同您的看法，按我的理解，您就是描述了串流播放时，用桥机解码的流程而已。
有两个问题：（我默认 ...

论坛发帖只是为了分享一下信息，而不是要争个谁输谁赢。

我了解的信息是达菲是从git库拉的代码自己构建的LMS和Squeezelite，并对LMS和Squeezelite的一些参数和配置文件做了调整，但是达菲的作者并没有对这两个软件进行源码级别的修改，因为按照规矩，对这种开源代码进行了修改并发布了软件 ，是需要同时发布修改的代码的。老外这方面还是很守规矩的。

我是基于达菲是使用了原版的Squeezelite代码的前提去做出哪些推论的。squeezelite并不支持所谓的不解码模式，同时LMS也不支持所谓的解码然后推送给squeezliete的模式，不相信的可以自己去看LMS和squeezlite的源码。

LMS有转码和SRC的配置。转码，比如FLAC可以转换为PCM，也许达菲的作者把这个叫做decoding force to media server。将一些压缩格式转码为非压缩格式的确能减轻一些解码的压力，比如让LMS将所有的非PCM转码为PCM然后squeezelite只用处理PCM，但这并不能带来多大的好处，因为在Linux系统中，所谓的CPU Idle，也是个特殊的内核线程，无非就是在跑Idle相关的处理而已（以上说的是CPU非节能模式），Idle高和低，只要不影响到正常的线程在跑，就没有关系。并且还有一个很重要的，实际上squeezelite的CPU占用率极低，除非是做SRC，否则性能相当差的硬件都能跑Squeezelite，都不说树莓派，就连ESP32这样为物联网准备的低功耗SOC，都能跑Squeezelite，基本能搞定96/24的格式的回放。

LMS和squeezelite都支持SRC，Resample那个选项是指定重采样到底谁来做，是Squeezellite Player还是LMS Server。另外LMS还有DSP插件，squeezelite也有DSP的路径（SRC再squeezelite就是一种DSP）。不修改源码的基础上，也只是能设置转码、SRC这些是在LMS上做还是在Squeezelite上做而已。但是无论怎么设置，squeezelite依然会跑stream/decode/output这几个流程，这可以通过查看squeezelite的线程来确定，一个主线程，另外3个分别就是stream/decode/output。squeezelite的架构是固定的，这些线程也是固定的，数据的流向也是固定的，不会存在绕过的可能。

关于你的第二个问题。我先解释一下那张截图。那张截图只是询问用户是否切换Squeezelite播放器所连接的LMS服务器，也就是说楼主希望将桥机的Squeezelite连接到核心的LMS服务器
当这样操作后，核桥的情况如下：
核心机（LMS+Squeezelite）其中Squeezelite不工作
桥机（LMS+Squeezelite）其中LMS不工作，并且Squeezelite连接到核心机上的LMS

这个界面和核桥谁来负责解码没有任何关系。只要采用的是LMS+Squeezelite，不管是使用达菲，或者PCP或者自己搭的系统，stream/decode/output这三个流程，都会在连接了DAC的那台设备（桥）上运行。这是LMS和Squeezelite的交互协议决定的，想了解细节的可以参考：https://wiki.slimdevices.com/index.php/SlimProto_TCP_protocol.html，以及Squeezelite的源码：https://github.com/ralph-irving/squeezelite。不理解底层原理仅仅通过上层界面去猜测发生了什么那并不靠谱，就如同我们天天用电脑也不会知道电脑的操作系统级别到底发生了什么以及是怎么运作的。

另外关于Buffer，squeezelite有多级buffer，stream buffer, decode buffer，output buffer，Linux内核还有一层alsa声卡驱动层的buffer，若是接的USB DAC，还有一层叫做URB的东西也有缓存。
这些Buffer都是异步处理的，可以想象为一级级的蓄水池，最关键的是底层的buffer不能under-run（欠载），就是不能空，空了就是噪音。至于说buffer的大小会怎么影响音质，这个就好比是在想多级蓄水池最顶上那级的大小和进水的稳定程度是否会影响到最底部的蓄水池的出水流速。这个我的观点很直接，在保证bit-perfect的前提下，各种软件设置并不会直接影响音质，最多也就是可能因为软件设置的不同导致硬件产生的电磁干扰不同会导致DAC出来的声音有所不同。建议是买个足够好的DAC，而不是在软件上做各种调整。或者，换个电磁干扰低的硬件来做桥。

这也是达菲作者的建议：

Q10. How should I configure the audio settings in order to maximize
     the audio quality?
A10. In short: Use bit-perfect playback and have good enough
     DAC. Longer version: My own view and experience is that if you
     have good enough DAC (using asynchronous data transfer from PC,
     independently powered, galvanic isolation between USB receiver
     and actual DAC+analog circuitry, etc...) any audio device
     parameters don't effect on sound quality as long as you use bit
     perfect playback and keep the parameters sensible so that they
     don't cause any buffer under-runs (and have also some tolerance
     for high system load situations). If the DAC does not meet those
     requirements the chances that computer HW+SW combination effect
     on sound quality are much higher and the effects may be caused by
     many unpredictable reasons (HW, SW, parameters, specific
     combinations of them, etc...). You just have to experiment and
     try to find the best setup (or buy better DAC ;-).

最后，
达菲并不等于LMS+Squeezelite，但如果使用者对Linux系统足够熟悉，达菲所做的优化和一些附加功能，直接在Linux系统级别通过安装一些软件和使用命令行，一样能够完成。玩核桥分离，不一定要抱死达菲的大腿不放，可以有别的选择，LMS可以在几乎任何系统上直接安装，桥也有树莓派上的PCP可以选择。但不管怎么弄，它还是LMS+Squeezelite，原理及核心就是那些东西。从完美主义者的角度来看，达菲做桥，除了Squeezelite播放器的进程在跑，还有LMS服务器进程在跑，为啥调这调那，就不想着直接搞个纯Squeezelite当作桥呢？

Victor_Derbobo 发表于 2024-11-15 17:10
看了您的文章，您对LMS等软件的了解值得敬佩。

咱们权当是探讨啦，我上面提的俩问题不知道您怎么看？

我實試了.. 樓主的(橋核分離) 玩法..

但... 基本聽不出有任何分別..