门的耳朵 发表于 2019-6-22 12:13:22

好多可以学习的东西

zaar 发表于 2019-6-22 13:14:16

爬完楼,心仪:$。

然鹅目前只能努力攒钱中:L。

希望等到攒够钱的那一天,这个玩意儿还没停产{:1_103:}。

aaalzaaa 发表于 2019-6-22 17:33:07

除了那根网线,这个网桥应该没什么遗憾了

Phase 发表于 2019-6-22 19:42:46

我觉得还是usb好,同轴容易闷

雪风 发表于 2019-6-22 20:05:17

跑个题,有个事儿没搞明白:如果usb传输中无时钟信号,那么W4S的recovery跟泰坦鸟宣传中的卖点——依托高质量时钟进行信号重整——从何谈起。。。

wwdd2018 发表于 2019-6-22 23:10:19

别老是和dcs那种牌子对标了,做好自己本分就行了,然后还是让市场来对标不是很好,同样一台pna和dcs的机器二手出,到底是pna好出手还是dcs好出手一试就知道了!!!不过买了土炮的拥有者总希望市场占有率越高越好,所以夸的过度点可以理解,以后出手容易点,不会砸手里:lol:lol

wwdd2018 发表于 2019-6-22 23:10:29

别老是和dcs那种牌子对标了,做好自己本分就行了,然后还是让市场来对标不是很好,同样一台pna和dcs的机器二手出,到底是pna好出手还是dcs好出手一试就知道了!!!不过买了土炮的拥有者总希望市场占有率越高越好,所以夸的过度点可以理解,以后出手容易点,不会砸手里:lol:lol

wwdd2018 发表于 2019-6-22 23:10:48

别老是和dcs那种牌子对标了,做好自己本分就行了,然后还是让市场来对标不是很好,同样一台pna和dcs的机器二手出,到底是pna好出手还是dcs好出手一试就知道了!!!不过买了土炮的拥有者总希望市场占有率越高越好,所以夸的过度点可以理解,以后出手容易点,不会砸手里

wwdd2018 发表于 2019-6-22 23:11:13

别老是和dcs那种牌子对标了,做好自己本分就行了,然后还是让市场来对标不是很好,同样一台pna和dcs的机器二手出,到底是pna好出手还是dcs好出手一试就知道了!!!不过买了土炮的拥有者总希望市场占有率越高越好,所以夸的过度点可以理解,以后出手容易点,不会砸手里

yuotube 发表于 2019-6-23 00:52:01

小白 发表于 2019-6-22 11:19
你的第一句判断就是错的,这是很基本的概念啊,光纤、同轴、AES、IIS传输的情况下都是数字源的时钟为基 ...

如此的话,解码的时钟岂不是个摆设?
或者说,如果能以解码本地时钟为主,不就能排除前端的时钟信号了?

yuotube 发表于 2019-6-23 00:54:35

andygaof 发表于 2019-6-22 11:01
开个玩笑,目前nBridge不少用户是ROCKNA,HDMI连接,实际结果是大家都选择了stream时钟。也就是ROCKNA跟 ...

就事论事,我弄不明白前端的时钟和后端的时钟是如何协调工作的

andygaof 发表于 2019-6-23 10:09:16

yuotube 发表于 2019-6-23 00:54
就事论事,我弄不明白前端的时钟和后端的时钟是如何协调工作的

这个比较复杂,现在贴不了图,我尝试用文字解释一下,这东西纯文字解释有点困难,希望可以看懂。

对于USB,老古董的同步USB我就不解释了,只说异步方式。首先要明确USB传送的时候是USB时钟,而不是音频时钟,后面的USB接收者收到的是以USB格式打包的音频数据。根据组合出的音频数据提供的信息,从里面知道当前播放音频的时钟信息,然后利用另外一个时钟系统,生成音频时钟,同时把数据以音频格式发送出去。也就是说,USB播放的时候,一定是接收端提供音频时钟,这个时钟的好坏对音频质量有决定性影响。对于USB的前端音频优化,绝大多数是在如何降低干扰,如何保证数据实时传输方面做工作。

对于音频格式,这个时候时钟系统非常复杂。

MCLK,主时钟,通常是22/24/M或者是45/49M,这个时钟信号在常见音频接口中只有IIS能够传输,SPDIF/AES不能传输。

WCLK,字时钟,基本可以理解为当前播放音乐的采样率。例如44.1KHz/16bit的字时钟是44.1KHz。

BCLK,比特时钟,是每个0/1对应的时钟,后端设备必须依赖这个时钟信号恢复出每个比特数据。比如一个44.1KHz/16bitPCM帧,由64bit组成(音频信号左右声道固定是各32bit)。那么BCLK频率是44.1*64KHz。

任何音频接口接收数据的时候,必须依赖前端的BCLK和WCLK来获取准确的数据和帧。但是后面的处理可能会有不同,有些解码器,会把这些数据缓冲下来,然后做reclock。有些解码器是直接利用这些时钟信息不再处理,直接交付解码芯片进行解码。前者看前端和解码器共同的时钟处理水平,任何一个不好都不行,但对前端依赖相对后边一种较小。后者主要看前端的时钟处理水平。

有些解码器,尤其是高端解码器,可以通过配置在两种方式切换。例如ROCKNA,时钟方式可以配置成LOCAL或STREAM。那种更好看前端能力。

小白 发表于 2019-6-23 11:34:23

本帖最后由 小白 于 2019-6-23 13:14 编辑

解码即便有buffer,也并不意味着可以依靠这个buffer去消除前端时钟质量的影响。这也是一个容易引起误解的地方——有些人以为解码里面有了buffer+reclcok就不依赖前端数字源了。其实无论解码内部如何工作,都依赖于数字源输出的质量,数字源的影响都非常大。有些解码器为了商业目的宣传所谓jitter-free、jitter-immune,事实上这种解码器并不存在。buffer+reclock、或某些升频处理,可以在一定程度上降低前端源的影响,但也只是“一定程度的降低”而已。如高总所说,对解码端来说,看“前端和解码器共同的时钟处理水平”,而且,简单地说,前端输出仍是“主”,是后端跟随前端,而不是后端说了算。

从经验来说。一个数字音源系统里,数字源的输出质量,决定了数字源+解码这个系统能达到的“天花板”高度。

小白 发表于 2019-6-23 11:46:39

我以前谈这个问题的时候打过这么一个比方——如果哪一天哪个解码器号称自己真的作到jitter-immune了,很容易验证!把它接到一台300块的DVD机的同轴输出去听,是否能出很好的声音。再和把它接到esoteric转盘后面听一下,比一下。如果是真正jitter-immune的解码器,应该能作到接300块DVD和接3万块转盘,声音基本一样(不说严格一样)。但是,在可以预见的未来,不会有这种解码器。数字源仍是非常、非常重要的。而且越是高档的解码器,对数字源质量的反映会更加灵敏(而绝不是更加迟钝)。Over。

nuaababy 发表于 2019-6-23 14:45:36

弱弱的问下,nbridge或者各类网桥需要有线网络还是wifi就可以
页: 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20
查看完整版本: 说下PNA nBridge网播(音乐网桥)的体验和声音

耳机俱乐部微信
耳机俱乐部微信