: 推 elguapo: 感谢解说。但我的point真的不是DAC的design问题。场景：M 07/13 18:51
: → elguapo: ac A 用 Dante 连 Mac B，Mac B 用 internal looping 将 07/13 18:51
: → elguapo: 音讯转给 USB DAC。Dante 和 internal looping 是虚拟介 07/13 18:51
: → elguapo: 面。请问音讯资料传递时，max A -> Mac B 传 Dante 时谁 07/13 18:51
: → elguapo: 是主钟？到了 Mac B，Dante 借 internal looping 到 USB 07/13 18:51
: → elguapo: 更正: Mac A 07/13 18:53
就我所知，Vitual interfac （自己）没有音频时钟
Vitual interface 可以不需要依存音频时钟，因为处理的只是数据流
在这我又要截一大段 Roon 讨论串中的对话救援
※
DAC 只能从其本地缓冲区中提取数据，因此它不关心上游的连接。核心只能将数据放入其
本地缓冲区，因为它不关心下游的连接。
RAAT 管理两者之间的数据传输，为了确保所有位元能够完整地从核心传送到DAC，它使用
网络本身提供的较低层级功能来确保数据的完整性。如果丢失一个数据包，将发送一个新
的数据包并按正确顺序放入缓冲区。如果数据包损坏，也是同样的处理方式。在大多数情
况下，缓冲区足够大，以使这个错误修复过程能够在DAC耗尽数据或核心填满其缓冲区之
前进行。
请记住，我在这里非常谨慎地使用“数据”这个词，因为这是音乐此时的形式。它是正在
播放的文件的位元串流。这是一个异步过程，对DAC的模拟输出没有影响。RAAT（以及网
络堆栈）在核心和终端之间促成了一个非常互动的对话。它们确保文件（不超过缓冲区的
大小）从核心复制到终端。
……
这是一个异步过程。根据定义，传输过程的时序（时钟同步）与解码过程完全独立。缓冲
区的填充和清空速率会变化，但只要DAC的缓冲区中有足够的数据，播放将会持续可靠进
行。
这里的关键是区分数据和信号的区别。正在播放的文件在其位元以实时方式通过DAC进行
转换之前，不会变成信号。在它们从DAC（或终端）的本地缓冲区中提取之前，这些位元
与用于文档、图像甚至本帖中的位元没有区别。
我理解发烧友不断尝试“改进”事物的渴望，这种行为实际上是这个爱好的基础。在过去
，当大多数概念与某些物理事物相关并且变化不仅容易展示，而且还可以通过一些逻辑解
释来支持时，这种改进更容易实现。然而，数字世界并非如此，因为其中许多概念与直觉
相悖，解释也更加复杂。
※
虽然 Vitual interfac 跟 Roon RAAT 有些差异，但本质上是相同的
当 Vitual I/F 的输出入是同 sample rate 时，Vitual I/F 的做用只是传递数据
音频数据应该被直接 pass through
当输出输入是不同 sample rate 时，会需要 SRC，但有两种选择
●其一是 SRC 采样率锁死，如 44100 Hz 转 96000 Hz 或等倍的 Oversampling
前端如果是 foobar 之类的 player、不会有时钟问题，就单纯的送资料填 buffer
但输入与输出端若有实体时钟差异会出现 Drift
我们的默认实现使用一种称为“填充”和“删除”样本的技术
基本上是插入或删除单个样本。
粗暴有效的解法，有可能出现爆裂声:D
●另一种就是用 Async SRC、也就是 Drift Correction，但 ASRC 开销大
Drift Correction 的过程一般 Vitual interfac 也是没时钟
因为前后端的进出的样本数差异，是前后端硬件的时钟差异造成的
视其中一方为主就解决了，依方向选好主角、另一个配合主角
至少我没看过有实践把系统主时钟拿进来凑一脚，让系统主时钟当主角的状况
但我猜这也是 e大您的理想
※
我上一篇推文中就有提过
Mac 的 Drift Correction 我上面贴的那篇也有提到
弥补的也只是 Audio device 间的 Audio clock 差异
跟 System clock 无关
就像这页里的第一个图
https://support.apple.com/en-us/HT202000
Clock Source 能选系统时钟吗？只有 Audio device 能选不是吗
从 e大当时的回答我就知道在段您想歪了

辛苦了！

我都用notepad开wav档来看，领悟音乐之美

您描述的内容，前题是电脑的系统时钟是稳定的。我在这一大串的讨论应该有提过，系统时钟并不稳定，说开大buffer就能解决只是逃避问题。若因作业需求必须分秒必争，将buffer缩小达成低latency，例如两地区即时收音、混音并即时播放，您会怎么做？（AES67 最大的应用是跨子网域做I/O。）

做Switch的打3天72小时不能掉包，DUT的X'tal也才+-50ppm而已，clock精度啥的其实还好，运作机制够强就不是大问题

问：AES67 在跨网域、跨国际运用时中间的所有 ISP 网通设备时钟精度会是 10ns 级或是 >100ns AES67 为什么能正常工作？答：依据GMC traceability 以及 HW timestamp 。@ganei 同步以太网路对交换器要求蛮高的，可以当 IEEE1588 BC 的交换器很贵…

我觉得e大要先看一下serial link and physical layer ，感觉e大还没有这两种概念

IEEE1588 BC 交换器也仅是L3。RTP stream 会把 Ref CLK资讯包含在内。每个 stream 里面的每个 packets 都打上时戳以便下一个节点recover clock。@bt092001 我手上有 AES3 AES5 AES11 规范的完整版，也有买 DAC 设计相关的丛书来念。或许我真的不是读书的料，若您认为我读的不够或是概念不足，可否建议我书单？

我觉得不是书读的不够，而是有点搞混，我先想请教如果今天，您今天一直强调主时钟同步，再您的观念中这个主时钟是如何传递给下一级？

就如同我在您的post的问题，手机即是ADC也同是DAC，为何ITU-T仍要指出5G network的同步问题及必须手段？您一直是用DAC PHY 去理解整个问题，并不认为同步传输是有意义的。我个人不会去challenge个人想法，我也会同意您的见解。但对于我的知识不足的部分，也请建议我书单，我会去读。

就以这个同步的主时钟来说好了，您认为怎么转传到下一级？如果以RJ45或是USB传送，并没有CLK 的IO接口，后级如何知道这个CLK?

“此同步非彼同步”：都是IEEE1588 implementation 请问有何不同？“后级如何知道这个CLK”：SDP 会标注 Ref clock 给后一级；若没有 GMC 则会用本身的 system clock 为 Ref clock。“因为这个同步是应用同步，而非传输同步”：AoIP 是同步传输的一种。

好，所以后一级只是知道前一级的资讯，如果后一级用自己的system CLK 去敲，是不是跟前一级的CLK不phase alignment？

“因为以封包为基础的网络传输过程，没有同步这回事”：SyncE 就是在改正这件事。@bt092001 后一级会变 slave

所以我先当频率一样，后一级的CLK 波形长相是不是跟前一级无关？

@bt092001 我想我已经表达过，您是认为DAC PHY可解决所有问题的人，前端长再丑都能搞定。我同意，不争执。我个人刚好是站在对面，认为DAC就是要听中央指挥的东西，不听指挥就抱歉移除，声音再好，不合群的也只能请离。应该没有人说DAC PHY是永远不能改动或改进去配合时钟同步吧？

爆音或静默？

E大的想法偏向parallels bus精神，但目前市售主流chip还是异步CLK

“爆音或静默？”：我熟悉的器材在侦测到 sample rate change 或是 GMC change 是自动静默，对齐了之后再发声。“这并不需要超精准时钟”：AES67主时钟规范同AES11，必须达 Grade 1。Grade 1“看似”不精准，但现有器材放眼望去还真的没几款。Sample rate change from 48KHz to 96KHz 并不是 drift correction 保护的范围；GMC change 若两个 GMC 的 ppm 差异不大（例如两个 Grade 1 GPS PTP GMC）那么顶多是显示重新锁定但音频不会静默（这部分是 SMPTE ST2110 的 redundancy 会讲到的）。如果是 Grade 1 降级到另一个 Grade2 的 GMC 就可能发生重新锁定过久而必须静默。顺带一提，若是采 SMPTE 规范，那么全部器材都要达 < +-5ppm 精度，比 AES 规范还严苛。“好像不用压到 10ns 的精度”：同意，确实是不用。新收的网卡有这个能力也很稳定，是意外收获。“纯粹是个人想像”：所以没有在用AES67的您是不是也用想像的方式否定这些使用心得？若我的假设是被您认定不科学且无根据，我ok。就此打住，不再回复。

推O大

建议e大看一下 Ethernet or usb or hdmi physical layer block diagram 而且最好能知道那些电路作用，还有那些IO到底传什么的定义，大概就能发现不合理处只要知道那些block电路用途跟IO传了什么就好

无论你用挂号印出来还是PDF寄email，内容没差sampling rate只是读稿机的语速而已跟想像的不一样，表示想像力有问题ww

那foobar 16bit时可以选dither是不该选吗？

我一开始就知道他想歪啊 XDDDdither的话，听无损没差，听有损的可以开有损的试过听了没差的话就不用开。有损的格式会有奇奇怪怪的模型压缩，开了"可能"会好听windows还会很贴心的帮你切掉peak。系统底层的切

想借这篇问大大们 我在VST软件上(以SIR3为例)调整音量的动作会影响档案的bit depth吗? 等等附图https://imgur.com/NdqQdu8 红圈部分感谢O大解惑~立刻挂上去foobar2000 2.0来串看看~