|
本帖最后由 xxbin1911 于 2024-8-22 21:11 编辑
写这篇帖子的起因有两个,一个是看到了一个不靠谱的商家在卖不靠谱的USB隔离器,另外还有个原因是因为在另外一个帖子很随意的说了一些混淆视听的话,可能会误导一些人。
我在那个帖子提出一个问题,如果数播所在网络中有和没有数据在传输,听音者能听出差别来么?我提出这么一个不靠谱的问题主要是想避免陷入一个万事万物都有关联的陷阱中。周边的设备对声音的负面影响我把它分为可闻的和不可闻的,如果用测量来判断,那应该是低于-130dB的可以作为不可闻的,那种不可测量的就更加不用考虑了。隔壁家开了空调理论上对声音有影响不?有,但是我觉得应该是不可测量的,我更是听不出来这个夏天到底邻居们开了多少空调。
现在数播开始流行,也有不少开源的数播解决方案,很多发烧友希望通过改造数播的电源,改进数播的晶振,使用HIFI交换机,使用HIFI网线、使用HIFI USB线等来试图得到更好的声音,恰好因为个人的兴趣原因,对这个领域也有些涉猎,所以开贴简单的聊聊网络和数播对DAC出来的声音影响,主要在数字领域,DAC之后的模拟领域在此不做讨论。
网络和数播对声音的影响,可以分为两个部分,一个是偏软件的部分,一个是偏硬件的部分。下面会稍微详细的说一说我的看法。
软件部分
首先看软件部分,播放器如果和音频源不在一台设备上,那么会通过网络传输音频流。通常,播放器会有一个比较大的缓存来存放通过网络传输过来的音频流,然后还会有个独立的解码缓存存放解码后的数据,在没有DSP处理的情况下,播放器还有一个软件的Buffer来存放将要播放的音频数据,而音频设备本身,还有一个更小一点的硬件Buffer来缓存音频数据,整个的一条路径上,缓存是相当多的,这是数字领域的一个特点,让两个环节解耦通常都会用到缓存(数字领域大量用到解耦的设计,解耦的意思可以理解为两者互相不影响)。从这样一条路径来看,网络传输得快和慢(只要不会导致最后得音频输出缓冲区空掉),以及网络中的偶发性丢包,都不会影响到最终输出的音频数据的准确性。而音频数据输出的Jitter,也不会受网络的Jitter,以及播放器的解码等环节的影响,最终的Jitter,取决于播放的音频设备硬件本身。那些号称网络音频流本身有时钟的纯粹是捣糨糊,可能连音乐所用的音频流编码是怎么回事都没搞明白吧(或者,就是一些商家在混淆视听)。
之前流行内存播放、实时内核等,以及各种内存锁定技术,还有类似模拟煲机的数码播放器煲机等等方式,其起作用的前提条件是DAC与播放器是同步的连接方式且没有有效的电磁隔离手段,比如DAC本身就是播放器的一个组成部分(内置声卡),或者DAC接收到的I2S信号是播放器直接输出(非USB转I2S异步输出),这些技术的本质有两个,一个是希望通过减少运作的硬件来减少一些电磁干扰(内存播放就不涉及到硬盘和网络了),另一个就是提高软件的实时性来试图达到更低的Jitter。数码播放器煲机有其技术原理的支撑,CPU的缓存是否命以及指令分支预测是否成功对代码运行是有影响的,一次缓存不命中可能会导致10-100个指令周期的延迟,数码煲机是可以一定程度提高CPU的缓存命中率和分支预测的成功率的。但是这些努力在有良好隔离的异步USB DAC面前就不再有意义了,会影响的,可能更多的是播放器通过USB音频设备输出时所用的硬件的最小Buffer大小以及发送的周期,如果是Bit Perfect的数据传送,所有的软件差异造成的影响在有异步升频(ASRC)的DAC环境下是否可测量我表示怀疑。
同步与异步
同步和异步可以用一个简单的例子来说明:
比如有个商家需要用非常精确的频率将固定大小的货物分发给买家,同步方式就是商家直接定时定点将货物送给买家,这个定时送货就很难,因为有各种影响的因素,比如路途遥远偶尔会堵车,还有刮风下雨都可能会有影响。那怎么办呢?商家直接在买家门口建了个大仓库,用卡车批量的将货物运到仓库,然后再雇一个人来定时定点的将小包的货物送给隔壁的买家。这就是异步模式。
买家收到货物的频率只取决于那个被雇佣送货的人送得是否及时(就在隔壁,这个及时性就很强了,也就是说抖动(Jitter)可以做得很低),而且重要的一点是,送货的人送货的频率和抖动,和卡车送货的频率和时间的耽搁(抖动)无关,卡车送货只要关心一点,仓库任何时候都不能空也不能满。注意这里我说的是无关,而不是完全无关,因为根据大多数的实现机制,这个异步的过程是有个锁的,卡车卸货的时候人不能送货,可以简单的理解为这个仓库就一个门,送货的卡车卸货的时候堵了门口,送货的人就出不来了。这个堵门造成的影响可能有点随机和混沌,大批量运货,堵门时间长,但是堵门次数少;小批量运货到仓库,卸货的堵门时间短,但是次数多。我个人感觉,可能卡车小批量运货到仓库,卸货的堵门时间越短越好(无测试数据作为依据,仅仅是自己的猜想)。
硬件部分
我简单的画个图,以铜缆(双绞线)传输为例,USB DAC输出,图不够不严谨,但是用来说明问题基本够用
----------------------------------------------
交换机/路由器
网络芯片(MAC + PHY + 晶振)
信号隔离变压器
RJ45插座
-----------------------------------------------
|
|
双绞线(TCP/IP over ETHERNET)
|
|
-----------------------------------------------
RJ45插座
信号隔离变压器
网络芯片(PHY + 晶振)
|
CPU+MEM+MAC以及各种总线(数播硬件/PC/树莓派等)
|
USB总线
USB接口
------------------------------------------------
|
|
USB线缆 (传输协议为USB Audio异步协议)
|
|
------------------------------------------------
USB接口
XMOS/FPGA/CPLD (时钟)
USB桥接芯片将USB Audio异步转换为I2S信号
-------------------------------------------------
|
| 内部或外部I2S信号
|
-------------------------------------------------
DAC
--------------------------------------------------
以上是简单的网络+播放器+USB DAC的一个示意图,先澄清几个概念和错误的观念:
1、RJ45网口(就是我们普通电脑和无线路由器用的网口),是带信号隔离变压器的,或者有独立于网口之外的隔离变压器,比如树莓派,就是网口本身带隔离变压器,没有隔离变压器的网口,按照规范要求,在网口和网络PHY芯片之间也需要加入隔离变压器;
2、我图上没有画POE供电,一些交换机以及树莓派支持POE供电,POE供电的话,是会将网络两端的两个设备的PGND连在一起的,普通不带POE供电的网络,网线只传输数字信号(树莓派如果不启用POE供电也仅仅是传输数字信号);
3、不建议用带外层屏蔽的网线连接播放器和网络设备,特别是那种带金属接头的网线,极有可能会与设备的PGND相连;
4、数播输出的USB信号的Jitter,和数播网络的Jitter无关;
5、异步也就意味着解耦,异步USB DAC也有一道多道解耦,也就是说XMOS等USB转I2S输出的I2S信号的Jitter,和USB总线的波形的Jitter无关;
6、播放器(电脑)上的一些晶振,是用来驱动CPU和各种总线用的,USB转I2S输出的I2S信号的Jitter与这些晶振无关;
Jitter与数据准确性
需要强调一点,解耦的设计并不是万能的,解耦也分完全解耦和不完全的解耦(这个是我发明的名词,仅仅为了表达不完全不完美的意思),比如USB和网络,这个是完全解耦的,跨光缆的网络设备之间(不考虑电源影响的话)也是完全解耦的。而异步的USB转换为I2S信号这个过程,很多时候是不完全解耦的。异步的转换通常会用到硬件的Buffer(缓存),输入的数据会填到这个Buffer中,当通过高精度时钟驱动从硬件Buffer中取数据时,可能会碰到正好在写入数据,而大多数设计(包括硬件)是带锁的,写入时无法读取,写完了才能再读取(参考前面仓库和送货的例子)。这样输入就会影响到最终输出的Jitter。而这个影响,并不是USB总线的Jitter直接影响到了I2S输出的Jitter,更多的可能是软件上的,比如播放器通过USB音频设备输出时所用的硬件最小传输块大小以及发送的周期,这个影响的数量级,应该远远超过USB总线的Jitter所带来的影响。
在USB转I2S这个环节,数据的准确性基本是无容置疑的,除非播放器做过音量调整等DSP处理,否则到达USB转I2S桥接芯片的数据应该是100%正确的,不正确的数据(under run或者over run)听起来就是破音或者噪声,数据的准确性不是我们应该关注的重点。而Jitter,通过上面的分析,也可以看出来I2S的Jitter并不会受网络的总线的Jitter的影响,甚至也不太可能受USB总线的Jitter的影响(否则就不能算做是异步了)。
除了数据准确性,Jitter,接下来就是电磁干扰了(待续。。。)。
|
|