双达菲（核桥分离）你玩对了吗？

xxbin1911

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的这个专利，有兴趣可以翻来看看。