作者bt092001 (一条鱼)
看板Audiophile
标题Re: [心得] 运用 Chrony 对时工具提升音讯品质
时间Thu Jul 13 16:33:15 2023
原文恕删
以下简易解释优化front end，
的DATA或是CLK是相对比较无效益的，
如有错误再请高人补充或改正，
另外关於介面传输干扰，包含PG noise，crossing talk ，ISI，SSO，GND bounce ，PSR
R问题先不在此列。
如下图截至ESS提出的原理
左边红圈为CDR/DPLL
因介面传输有非理想效应，
这些传输不佳讯号不能被直接数位电路使用，
所以需要重整DATA，
右边为OSC 或是本地CLK
专门给DAC cell使用，
当CLK正或负源触发後将DATA送给DAC，
*OSC物理电器特性是一个固定低频高性能的CLK
故我们知道最终决定抖动性能就是这个本地CLK，
前端很差或是被DIGITAL PHY暂存都只是
被看作latency 的表现不影响最终性能，其他类比干扰暂不在此讨论。
https://i.imgur.com/JgIngMU.jpg
这时有人会说DATA错了怎办？
通常晶片内有digital PHY或是controller
如果DATA效能差到规格外，搞得PHY神经了，是会解不出来或是time out，声音是打不出
来的。
内部数位的过程因为设计时晶片EDA tool都会评估DATA 跟CLK的skew故可以放心，如果真
有问题量产晶片测试时会被刷掉不会流到消费者端。
以下两图是市面上贩卖的主机板内建以及外接USB DAC 晶片的data sheet ，红圈所示为
这个原理的实践
https://i.imgur.com/7XIGNUe.jpg
https://i.imgur.com/IW2N5Bg.jpg
感谢板上先进，如有错误再请板上先进修正
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.137.239.156 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Audiophile/M.1689237197.A.AFE.html
※ 编辑: bt092001 (223.137.239.156 台湾), 07/13/2023 16:35:37
※ 编辑: bt092001 (223.137.239.156 台湾), 07/13/2023 16:35:52
1F：推 icekiba: 大肠面07/13 16:38
2F：→ evadodoya: 多加香菜07/13 16:40
3F：推 djboy: 可能要在结论区加一句：「系统的GLOBAL CLOCK没有对准， 07/13 17:03
4F：→ djboy: 可视为前端有状况，但是均己被DAC後端解决掉」07/13 17:04
5F：→ djboy: 这样子，原原PO才看的懂07/13 17:05
感谢补充，的确是这样理解，如果状况大到PHY看不懂，资料是送不出来的
※ 编辑: bt092001 (223.137.239.156 台湾), 07/13/2023 17:12:19
6F：推 kshieh: 原原po有说到在USB DAC做resampling时需要准确的时间，才07/13 17:16
7F：→ kshieh: 会算(interpolate)出正确的结果？ 07/13 17:16
8F：→ kshieh: 更正：是电脑做resampling
07/13 17:18
这样意义不大，因为听到的声音的CLK是DAC 本地CLK在送，电脑端的东西也只是被DIgita
lPHY存起来视为系统latency 而已
9F：推 Oswyn: 目前主流就是传输为异步，明示两端被不同步的 buffer 分隔07/13 17:19
10F：→ Oswyn: 而 DAC 还是工在同步模式，所以 DAC 依赖的时钟源很重要07/13 17:19
11F：推 greg7575: dpc latency 大到让音乐起肖的状况也蛮常发生(07/13 17:27
12F：推 greg7575: 封包，你退下。07/13 17:28
※ 编辑: bt092001 (223.137.239.156 台湾), 07/13/2023 17:36:25
13F：推 comipa: 所以为什麽之前很多人玩PC讯源都是先干了p/c state这类07/13 17:37
14F：→ comipa: 另外电脑算什麽都不用准确的时间 是要准确的clk,连时间都 07/13 17:37
15F：→ comipa: 是以clk为基础算出来的. 电脑内有时间观念的硬体大概RTC吧07/13 17:37
16F：→ ganei: 玩过走USB 1.x的 DAC就知道DAC起乩其实也还好，重插RESET一07/13 18:08
17F：→ ganei: 下而已(重新同步)，顶多一直断电重开有点烦，等哪天受不了 07/13 18:08
18F：→ ganei: 自然会换走2.0非同步的新机... (不便引发的购物冲动 07/13 18:08
19F：推 icekiba: 1.1没几年就2.0化了 07/13 18:10
20F：推 elguapo: 感谢解说。但我的point真的不是DAC的design问题。场景：M 07/13 18:51
21F：→ elguapo: ac A 用 Dante 连 Mac B，Mac B 用 internal looping 将 07/13 18:51
22F：→ elguapo: 音讯转给 USB DAC。Dante 和 internal looping 是虚拟介07/13 18:51
23F：→ elguapo: 面。请问音讯资料传递时，max A -> Mac B 传 Dante 时谁07/13 18:51
24F：→ elguapo: 是主钟？到了 Mac B，Dante 借 internal looping 到 USB 07/13 18:51
25F：→ elguapo: DAC ，这时的时钟如何转换？ 07/13 18:51
坦白说只要合规前端并不重要，
因为到DAC前可能过了无数个PHY，他们之间只要DATA对，
其他firmware,software,hardware 之间
如何handshake 转了什麽格式的资料或是时钟，只要合规走最高规互相能看懂就好，
但详细还要去看各个介面的spec 。
最终性能决定还是在最终段
26F：→ ganei: 记得2003年左右就有pcm2702的pcb可以玩，2.0 非同步的07/13 18:52
27F：→ ganei: audio 介面出来要到2010去了(XMOS方案)，有本事拿Cypress07/13 18:52
28F：→ ganei: 晶片或FPGA自干的论外，这大概比日本制压缩机还稀少07/13 18:52
29F：→ elguapo: 更正: Mac A07/13 18:53
※ 编辑: bt092001 (125.228.98.41 台湾), 07/13/2023 19:33:15
30F：→ greg7575: 古早拿270x 虾机八搭棚的一堆啊，好玩 07/13 19:40
31F：→ greg7575: xmos 粗乃还是有一大堆receiver活得好好的( 07/13 19:41
32F：→ greg7575: usb刚粗乃的时候cs8xxx这些转IIS的很热门 07/13 19:42
33F：→ yamatai: 这种说法已经十几年 还是没解释为什麽电脑不同声音不同 07/13 19:50
内文有说排除，类比串扰，这边讲的是系统理论，CLK一样DATA一样就是一样，但这里没
讲类比串扰哦，系统隔绝能力，noise 样态大小这些都是可能不一样的点
而且chip 都还有PVT的偏移，要计较的话多的是可以计较的
※ 编辑: bt092001 (125.228.98.41 台湾), 07/13/2023 19:55:39
※ 编辑: bt092001 (125.228.98.41 台湾), 07/13/2023 20:33:23
34F：推 djboy: 其实，现在都2023年了，AKM/ESS的高薪RD也不是吃素，能做 07/13 21:49
35F：→ djboy: 能改的应该都全下了(除了COST DOWN版本，这也是尽力COST07/13 21:50
36F：→ djboy: DOWN)。DAC IC 大概也就如此，除非有天才或是架构性的突破07/13 21:50
37F：推 dancehotdog: 产品会往cp值发展 不太会只考虑音质 就像3C一样 到最07/13 22:03
→ dancehotdog: 後就不见得是特定族群喜欢的 07/13 22:03
38F：→ yamatai: 类比串扰 noise 样态 也只是你的假设阿07/13 23:03
39F：→ yamatai: 如果这麽简单那 DAC 把隔绝能力拉高不就无敌了07/13 23:04
拉很高那有没有代价，这个代价也可能影响其他电器特性
40F：→ yamatai: 问题就是现在没有任何 DAC 可以改变电脑不同声音不同现象 07/13 23:05
并没有很简单，这些相容性情况组合变因有无数种，不能感觉，
如果要这样算今天85度跟30度电器特性改变10%人耳是否能听出来？
或是人耳是否能人耳分辨FF SS chip?
而且不是是假设啊，系统理论事实上会发生啊，
今天假设高温你今天GPIO device刚好在FF，
DAC core刚好在SS如果SSO发生，
gnd bounce垫个10-50mv你DAC INL DNL早就掉了，
而且这个刷量产因为在规格内还刷不到，
还有dac chip厂不是系统厂前端或是系统端没做好是管不了的，
然後你今天VBUS是吃线电或是DCDC，chip看到noise长相也不同，
而且chip当下的PVT的PSRR长相也有无数组合
相容性的东西不可能做到这种程度，只能定义一个可接受误差范围作为规格让系统go起来
电器特性的改变就是系统规格可以接受的误差
41F：→ yys310: 有哪台DAC隔离能力高到无敌了吗？ 07/13 23:09
推 icekiba: 高价的隔离能力搞不好还很差XD 07/13 23:15
42F：→ yamatai: 没有吧 很强调技术的厂牌隔离能力都很高了吧 07/13 23:22
隔离能力是chip隔离还是PCB技巧？还是chip间相容性？
切的很乾净是多乾净？有没有代价或副作用？
或是加强LDO?今天拉高PSRR，瞬间抽电的恢复能力变差就是代价，
电路的东西要取舍的东西太多不是非黑即白没有无敌的那种事
※ 编辑: bt092001 (125.228.98.41 台湾), 07/14/2023 00:06:21
※ 编辑: bt092001 (125.228.98.41 台湾), 07/14/2023 00:11:58
※ 编辑: bt092001 (125.228.98.41 台湾), 07/14/2023 00:13:32
※ 编辑: bt092001 (125.228.98.41 台湾), 07/14/2023 00:20:25
43F：推 louis0407: 觉得这篇原Po讲得很好xddd07/14 00:52
44F：→ elguapo: 音频资料在使用/传递过程若有吃到系统时钟的部分，将系07/14 02:36
45F：→ elguapo: 统时钟校正，不正是呼应您说的「要合规走最高规」？07/14 02:36
您误会这边讲的合规跟走最高规的意思，
随便指一个案例，能走U2传就不会走1.1，
原资料能传32bit 192k就不会下降到16bit 48k
硬体支援的话都是用最齐全的资料流在传
根本不用管他Master clk用多少去敲，每家chip 还不一样咧。
去调front end clk精度无意义，
interface ISI jitter 超大，你前面多准，也都被介面传输jitter 搞超大这样有用吗？
如果用对时角度去看你只是让delay往前或往後而已，但重点不是延迟时间而是jitter
你前端jitter 是1ps或100ps都一样，DAC如果5ps jitter 过了DAC 就是看DAC 5ps的jitt
er
不知道这样是否理解
不知道为何原po一直很在意延迟时间，早或晚打出data不影响声音品质阿
46F：推 greg7575: 电源线没差的话，设备就不用买双屏蔽超级小黑线了07/14 07:20
47F：→ greg7575: 整台电脑都换掉，产生的改变也当然会存在07/14 07:21
48F：→ greg7575: 即便是流水生产的，以高频探头为例。还是要各别校对07/14 07:22
49F：→ greg7575: 只是现在没生产出拉普拉斯的妖怪，没办法确定一切07/14 07:23
50F：→ greg7575: 无论再怎麽电路隔离，元件以及机箱内的环境都会有噪07/14 07:24
51F：→ greg7575: 噪除了电路，还有元件工作电磁波反射、外在电磁波引入07/14 07:25
52F：→ greg7575: 跟夸父追日一样，追不到。追的过程又产生新的问题07/14 07:25
53F：推 greg7575: 版子上面元件间距，会不会产生涡流，一堆鬼故事07/14 07:29
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 08:48:55
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 08:54:22
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 08:57:35
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 09:00:03
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 09:08:24
54F：→ elguapo: 行动无线通信，手机基本上也是一个DAC（最後要变成声音）07/14 09:10
55F：→ elguapo: ，按照您的意思，ITU-T对5G通信网路要求同步是没有意义07/14 09:10
56F：→ elguapo: 的事，对吧？07/14 09:10
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 09:13:12
应用不同啊，这里是音响hiend 相关应用，
你今天听音响会在乎声音早1ms或晚1ms发出？还是比较在乎声音品质？
而且serdes 的原理使用本来就是会切断前面的clk用自己的clk
对於DAC的系统的角度，前面不论花多少功夫再准再校正，DAC只会认为他是一个延迟时间
。
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 09:16:30
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 09:20:14
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 09:33:28
57F：推 kshieh: 我想e大应该是陷在AoIP的坑了，时间同步是为了接收端正确 07/14 09:36
58F：→ kshieh: 的重组packetized pcm data，接收端de-packetized後，就无 07/14 09:36
59F：→ kshieh: 需那个时间资讯，直接把pcm stream丢进去i2s audio i/f输 07/14 09:36
60F：→ kshieh: 出就可以了 07/14 09:36
61F：→ elguapo: 应用没有不同。AoIP 本质就是同步网路（用的是IEEE1588 07/14 10:07
62F：→ elguapo: 的media profile），而AoIP也有 Hi-end 产品（Merging NA07/14 10:07
63F：→ elguapo: DAC）。若照您的意思AES67的同步也是没意义的，反正DAC07/14 10:07
64F：→ elguapo: 都会修正一切。请问DAC会处理两三个DAC之间的时间差异吗07/14 10:07
65F：→ elguapo: ？07/14 10:07
假如你是平行三部一样的DAC，三部的jitter 量是一样的，如果前端过的PHY或是cable
不同，这三部的延迟会不同，所以你要的应用是多部平行的DAC，同时发讯号？
这样理解你要的应用对吗？
如果是这样的应用就是让DAC吃同一个外接或是本地CLK且skew一致并且这几部的DATA sk
ew要在一个UI内，这样就隔绝前端CLK并且DAC同时输出
ASE67只能同步DATA skew到DA家门口
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:30:02
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:33:08
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:38:02
66F：推 kshieh: 传递延迟就是在网路容量规画时要考虑的，再来就是把QoS设07/14 10:43
67F：→ kshieh: 好。pcm资料离开AES67网路後，DAC就是单纯拨放而已07/14 10:43
68F：→ kshieh: AES67的时间同步是重中之重。只是你可能吧AES67的工作范围07/14 10:46
69F：→ kshieh: 想得太广了些07/14 10:46
不确定原原po要的应用是不是多部DAC同时播放，感觉上是那个意思，但是其实那样也
跟AES67无关，因为串列传输会隔掉上一级clk
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:47:49
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:49:21
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:49:43
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:54:14
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 10:58:13
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 11:10:36
70F：推 kshieh: 看了一下Merging+NADAC的产品说明，他们有提到一句"it use 07/14 11:06
71F：→ kshieh: s a professional protocol called RAVENNA to manage the 07/14 11:06
72F：→ kshieh: data transfer and ensures a very high level of data i07/14 11:06
73F：→ kshieh: ntegrity and a timing accuracy of 1 nanosecond"看起来07/14 11:07
74F：→ kshieh: 是很优是吧？可是假如不走网路用同轴线直连(这台DAC也能直 07/14 11:07
75F：→ kshieh: 连)的话，根本就没有这个timing问题 哈07/14 11:07
76F：→ elguapo: 有个软体叫做「Dante Via」，可以把另一台电脑的 USB DAC07/14 11:11
77F：→ elguapo: 变为 Dante network 的一部分。您可以拿这个东西实作：A07/14 11:11
78F：→ elguapo: 电脑Dante，B 和 C 电脑Dante Via，B 和 C 电脑各挂一个07/14 11:11
79F：→ elguapo: 不同品牌的 USB DAC，然後 A 电脑将 B 和 C 的 USB DAC07/14 11:11
80F：→ elguapo: 作为 4ch 输出（就当作做 2.2 分频），请问主时钟会是 07/14 11:11
81F：→ elguapo: 哪一台电脑？那台电脑的时钟来源又是什麽？ 07/14 11:11
82F：→ elguapo: @kshieh Ravenna是AoIP的一种，符合AES67规范。 07/14 11:13
我大致理解e大的想法但跨越PHY不是所谓的主时钟概念，都是使用本地CLK，其他都是成
串封包内含DATA以及CLK的资料编码，但不是用这个CLK在传，走乙台网路就是用乙台网路
发射速度，封包内涵音讯的资料跟clk rate资料这些都被视为DATA，你所谓的主时钟同步
对於系统只是同步DATA skew，而不是同步DAC CLK，这些DATA skew只要在一个UI内，两
部DAC就不会看错资料
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 11:34:01
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 11:38:18
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 11:41:17
83F：推 djboy: BT大辛苦了07/14 11:58
85F：→ elguapo: webinar 资料，描述是 local clock 被主钟同步 07/14 12:00
86F：→ elguapo: Fully 这个辞意应该不是只有 skew 07/14 12:01
87F：→ elguapo: 对不起更正，”precisely” 07/14 12:02
88F：→ elguapo: slide 是指出 local clock 是 GMC 的 copy* 07/14 12:08
这时文件定义的问题对於你只看dante 来说是，但是对於以最後一级为DA全系统来说的物
理意义不是
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 12:36:26
※ 编辑: bt092001 (223.137.239.156 台湾), 07/14/2023 12:37:20
89F：推 kshieh: 我再读了一遍e大提供的webinar投影片，的确是有提到若是fr 07/14 15:17
90F：→ kshieh: ee run，alignment of streams是1/2 sample time 。以48kH 07/14 15:17
91F：→ kshieh: z来算，约是10us。若pcm下i2s时能控制BCLK的起始时间，的 07/14 15:17
92F：→ kshieh: 确能做到更精准的multi stream alignment… 只是一般家用 07/14 15:17
93F：→ kshieh: 系统都是在传mux好的双/多声道讯号，自然没有alignment问 07/14 15:17
94F：→ kshieh: 题。 07/14 15:17
95F：推 kshieh: 我是觉得 不是大型场馆的应用 明明可以有更可靠的方法 却 07/14 15:39
96F：→ kshieh: 硬要跑进水(ip network)里，用来奥林匹克等级的泳技，结果 07/14 15:39
97F：→ kshieh: 速度还是输给陆地慢跑的阿伯… 07/14 15:39