按照18楼的设置，QQ音乐就推送不到达菲了，怎么破呢？

双达菲“核桥分离”没错，都是达菲玩的开心就好

卧槽，双达菲玩法能炸出那么多技术大佬。
文科生表示大多看不懂，还是达菲upnp插件+HQPE+NAA的玩法简单无脑更适合我

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

哈哈，经过你们提醒

nas（LMS for docker）+无风扇静音达菲小工控机+xtune终于实现了手机控制播放界面好看，然后达菲不开用手机播放，开小主机，用台机播放，舒适了

现在听歌还是好看方便是大头，然后好听，以前一直喜欢用music_tag_web自带的subsonic服务器，因为软件，歌手、歌词、专辑界面显示齐全美观，然后刮削又十分方便，手机用起来特别好，但是美中不足就是不能无线遥控连接到解码器，想用dlna到达菲小主机，但是支持subsonic的软件dlna兼容性一直也不咋滴，达菲和subsonic两种服务器两种软件来回用着太麻烦了，而且小主机配置太差，歌曲库10w+就很费劲，这样好了，nas性能还不错，小主机就播放器就行了

希望大佬能加入歌词显示就完美了

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

大佬，你的nas+lms，是把lms装到nas的docker里面了，还是单独弄个主机smb到nas呢，我看lms不是独立的系统呀

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就是一段正确的废话。

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