统计的一些通讯Jitter, 做成图，帮助大家有个概念。

HHYYTT

这是一个20ms一次的数据通讯系统，收到数据时记录一下系统时间，可以看到数据基本都在20ms基准，但是会有个别的数据在时序上超出20ms，导致系统突变。
如果还有人相信，网口界面，除非不是TCP的，就只能呵呵了。其实USB3.0或者Type-C，以及光纤，都比网口TCP强多了。
上面的这些硬件接口，包括网口，只要速度够快，延时Latency小于10ms（这得很烂了），没有误码，也都可以的。
关键1是DSP的有没有能装下10毫秒延迟I2S数据的Buffer（以24bit192k，需要24/8*192*10*3=11520bytes，还要加上I2S控制码等，还是很大的，11KB多），或者DAC芯片有没有这样的Buffer。
关键2是DAC读取这个Buffer的时序的Jitter能处理到什么级别了，真要有发挥飞秒晶振的能力，那就厉害了。
DAC的DSP和DAC芯片不过关的情况下，什么数播，什么界面都是浮云，都只是重口佐料+普通食材，做的重口菜而已，大家喜欢吃而已，但不是什么好饭。
然后到了DAC的模拟部分，就只能掩盖数字部分的瑕疵了。

gebegebe

但是不同的数字输出听起来也不同啊

aarwwefdds

楼主似乎是拿TCP研究的 但是没什么代表性 而且把很多概念混为一谈了

首先大多数网卡本身具有gso gro rsc等功能且默认打开 会将数据包组合到一起再产生IRQ减轻CPU负担 副作用是会造成延迟抖动等问题，这个是非常正常的。通常幅度较小而已。

其次TCP本身就不适合延迟敏感应用 它本身就有的窗口机制、buffer机制以及ACK机制决定了它注定会产生非常大的抖动问题，少则小于1ms多则几千ms。所以在对延迟敏感（例如VoIP）的应用里基本都使用UDP

大多数“网播”都实现了一个嵌入式系统 具有CPU和足够的内存容量 并且自身就可以缓存来自网络的数据 因此完全不需要担心网络上的延迟抖动问题。“网播”的网卡接收到数据 传给它的CPU CPU再将此数据处理后送入数播内部的数字输出 剩下的就是数字输出怎么做的问题了。这些一系列缓存和数据处理肯定会引入不小的延迟的 但是人很难感受到而已

这里需要插一句：任何“低延迟”都可能对音质产生坏影响 欣赏音乐本身完全不需要低延迟！

因此网播等数播自身从概念上说并不具备比PC+USB界面更优异的能力 倒不如说它本身就是一个小型PC。其实际对音质的影响是由其数字输出（假设是SPDIF/AES3之类的输出）的设计水平决定而已

另外多数的DAC芯片自身并没有什么缓存机制 DAC芯片很简单 你给它I2S之类的数据（这是时钟同步的 缓存基本没有意义 除非DAC自身要做ASRC 那才会需要一点缓存） 它给你输出模拟信号。只有USB这样的界面芯片才会有一点FIFO缓存 例如USB异步界面会打开一个反馈Endpoint 告诉PC应该给它塞多少数据 使得缓存不溢出也不欠载。然后USB界面芯片自身作为主时钟 以自己的时钟发生器（例如有源晶振） 给后端的DAC喂数据。此时理论上来自USB总线的抖动已经被完全的隔离 输出的I2S信号抖动由USB界面芯片及其晶振设计影响

因此研究下来你会得到一个结论 折腾了那么多真的不是开了脑放？

当然 实际情况就复杂些：
1.SPDIF输出水平各家都不太一样 专业的数字输出 “通常”时钟都会更精确 抖动都会更低。（所以 数播理论上会有用）。更低的抖动会降低解码器的SPDIF界面PLL的压力 使得其输出的I2S信号时钟更稳定。
（然而你不觉得如果纯粹为了解决抖动投资几千块搞个数播不如搞个好点的USB转SPDIF界面更好？）

2.SPDIF会受各种外部因素产生抖动 所以一条好的SPDIF线理论上也有一定的帮助。但是好的SPDIF界面的PLL设计可以将抖动压的很低。
然而比较遗憾的是SPDIF芯片在解码器内部不是谁都能换的。所以预算有限的情况下去买高价线还是换个好解码自己考虑

3.USB界面芯片各家的水平也不一样，产生的I2S时钟有好有坏。
（好在我们还有SPDIF 可以用好的USB转SPDIF界面解决这个问题？

4.USB音频标准 传输数据使用的是同步类型Endpoint（这与音频传送本身是同步还是异步无关） 其本身是没有错误纠正机制的，但一条合格的USB线正常距离正常情况下产生错误的概率非常非常低。而非正常情况下 USB音频标准认为低延迟比错误纠正更重要。不过有些USB界面芯片是从VBUS取电，会受到来自VBUS的糟糕供电影响其性能。这取决于解码器/独立界面自身设计
所以USB线有用么？有多大用？这个得自己思考

5.买了好东西以后的脑放大开 也有很大的帮助

天蝎日影

完全看不懂

夜惊风

楼主讲的是网口PC界面，但是自己都已经把网口传输的数据搞混了

与PC通讯网口传输的是数据包，而不是I2S数据，界面的网口通讯芯片对于所谓的数据延迟，关于I2S的JITTER，完全是两码事

大家坛真的有很多这种人，完全不懂电路架构实现的是什么功能，却大着嘴巴宣传原理批判。

HHYYTT

夜惊风 发表于 2017-4-5 09:40
楼主讲的是网口PC界面，但是自己都已经把网口传输的数据搞混了

与PC通讯网口传输的是数据包，而不是I2S ...

我讲的是DAC数据处理合格的基础上，不误码速率够的数据途径对于jitter没有影响，FIFO只会造成整体时延。

夜惊风

HHYYTT 发表于 2017-4-5 09:59
我讲的是DAC数据处理合格的基础上，不误码速率够的数据途径对于jitter没有影响，FIFO只会造成整体时延。

还是先去学习一下网口界面的电路架构和原理再来讨论这种问题吧
关于你说的所谓延时，网口界面一般会配搭8M以上的SDRAM，别说几十个MS，就是给你延时几十S都足够了



再者，TCP传输有后向纠错，基本无视误码

HHYYTT

夜惊风 发表于 2017-4-5 10:08
还是先去学习一下网口界面的电路架构和原理再来讨论这种问题吧
关于你说的所谓延时，网口界面一般会配搭 ...

TCP包如果有误码，这个包是全部重传的。而且是双向确认，造成的时域波动还是挺正常的。
8Mb，其实也不大，只要系统取的够快，不然也就丢弃了。
不过这都不是问题，一般都会在系统大缓存，整体播放延迟几十到几百ms而已，这个是延迟，不是jitter。就是投个方便。

aarwwefdds

HHYYTT 发表于 2017-4-5 11:07
TCP包如果有误码，这个包是全部重传的。而且是双向确认，造成的时域波动还是挺正常的。
8Mb，其实也不大 ...

所以你总体想表达啥呢...我已经看不懂了

蓝子风

传输的数据制式不同，包含注重的地方不一样，楼主完全偏离了。。。。。。

争论的也是。