RAAT and clock ownership https://community.roonlabs.com/t/raat-and-clock-ownership/6915 这是个很长的讨论串，但内容应该不太复杂 把重点放在两位 Roon 员工对使用者提问的回答 brian | Brian Luczkiewicz | Roon Labs Founder AMP | Andrew P | Roon Labs 在此为了方便阅读用 Google 英翻中，挑重点不然篇幅太长，有疑虑请参照原文 其实对本话题有兴趣的朋友，都应该要去看完整原文 只有完整从头看到尾，才能真正理解 Roon 在讲什麽 在此我只能简单的拉出一些关键段落 但其实大部分的内容都很重要，且有前後连续性（删很多还是很多 ※ 关於音频时钟的大多数讨论都集中在时钟质量，而不是时钟一致性。本次讨论是关於後者 的。“抖动”这个词不属於本次讨论的范围。RAAT 对该领域没有影响。它异步移动音频 缓冲区，就像 USB 一样。它不参与生成驱动 DAC 的时钟信号。 在最好的系统架构中，您将拥有一个时钟：DAC 附近的高质量时钟。该时钟负责准确地输 出数据（低抖动等），并负责设置流经系统的数据缓冲的速度。 ※ RAAT 流媒体永远不会添加时钟差异源。 不要将流媒体视为设备的扩展，而应将 RAAT 视为 Roon 的扩展，让 Roon 出现在流媒体 上。 ／ 在 RAAT 的架构中，在单区域播放期间，RAAT 或 Roon 中永远不会发生推送。 （多区域播放时，其中一个区域“拉”，Roon“推”到其余区域，利用从第一个区域恢复 的时钟来控制速率。这是不可避免的，因为没有办法强制多个区域独立时钟源一致，因此 在这种情况下，我们需要使用如上所述的漂移补偿技术。） ※ 因为 Roon 要支援「网路多区域播放」，因为有多个设备所以数据传输管理才更复杂 Ｑ：因为听起来我们不需要过度担心除 DAC 之外的任何时钟的质量，因为 RAAT 正在为我们 解决这个问题。这是真的吗？ 是的，这是正确的。 ※ ↑如果觉得太多字，看完这句回答就可以回上一页了 对於多区域，我们在拉动模式下运行已被选为主时钟的区域，并推送到其他区域，这些区 域被迫在内部补偿漂移。 实际的实现是稍微间接的。核心知道将数据包发送到端点的速度不是因为明确的数据请求 ，而是因为核心知道驱动音频流的高分辨率时钟的时间，并且它了解挂钟时间之间的预期 关系和直播时间。它的行为类似於基於这些时间关系+与端点时钟的定期同步的软实时系 统。 ※ 是的，S/PDIF 信号以自己的速度传送样本。异步重采样是 DAC 用来解决这个问题的一种 技术，但还有其他技术。 可以简单地忽略这个问题。这是一个消费级解决方案，但您完全可以仅使用传入的 S/PDIF 信号来驱动整个过程并忽略（或省略）内部时钟。 一些 DAC 会缓慢调整其内部时钟以适应输入速率，使用小型缓冲区来防止溢出/欠载，然 後重新计时数据输出。我知道 Meridian 产品就是这样工作的，但它们并不是唯一的产品 。我猜测 MSB 使用了类似的方法（知道他们制作了梯形 DAC）及其营销材料 8表明我是 正确的。 已经内置了大过采样级的 DAC 可以协调现有重采样过程中的时钟差异。ESS Sabre 的技 术文档是支持 USB DSD 的 DAC 中非常常见的芯片，在本文档的第 III-B 节中对此进行 了讨论 9。我的理解是，这是基於 Sigma-Delta 的 DAC 最常见的方法。 为什麽这样可以？因为这种转换不会对信号质量造成实质性损害，因为过采样率非常高。 ESS Sabre 正在对您的信号进行异步重新采样，频率约为 40mHz。与从 44100->44100.005 相比，这对质量的影响要小得多。 ※ 实际上没有数据请求 - 服务器正在根据其自己的周期性同步对主时钟进行建模，并使用 它来驱动传出数据速率。该技术简化了主区域和从区域之间的协议级别差异，因为它们都 可以使用相同的原语来管理流。只有一个额外的命令（“与远程时钟同步”）用於从站。 每个端点都有几秒钟的缓冲区，并且缓冲区保持在半满左右，因此，如果数据暂时太快或 太慢，就有时间使时钟保持一致，而不会超限或不足。 从设备使用与服务器引导传输速率相同的机制来同步（“恢复”）主设备的时钟。时钟误 差测量通过响应缓慢的低通滤波器，因为当测量有噪声时，此类系统容易出现振荡或过度 校正。每个从属设备都知道自己“领先”或“落後”多少，并且可以相应地进行调整。 Async SRC 是一种可以使用的技术，但不是唯一的选择。我们的默认实现使用一种称为“ 填充”和“删除”样本的技术 - 基本上是插入或删除单个样本。与典型的实现相比，我 们的实现有所改进，因为它尝试定位流中的位置来执行可听度较小的插入/删除，并且它 使用 RNG 来定位校正，因为周期性声音更容易挑选出来。 我更喜欢这种方法，因为校正不会影响音频，除非它们发生（使用异步 SRC，会产生持续 的效果，并且以非常高的质量水平执行异步 SRC 非常昂贵）。在没有太多 CPU 空间的低 功耗端点上使用此方法也更实用。 我们一直在考虑将漂移调整转移到服务器的想法，这可以允许更密集/更昂贵的技术，因 为我们有更多可用的 CPU 资源。还有一些愿望可能支持跨不同技术的分组播放，这几乎 肯定会引导我们朝这个方向发展，因为每个人的系统工作方式都有点不同。 ※ 传送过程基本就是在填充与提取 Buffer，过去我在 WASAPI 相关讨论串中也提过 Ｑ：因此，如果 RAAT 的设计方式意味着唯一“相关”时钟是 DAC 本身中的一个实现（假设 Roon 端点为 USB DAC），那麽专用 PCIe USB 板上的所有那些深奥的 USB 时钟发生器 和高端时钟都可以从技术上讲，find 没有执行任何有用的功能 RAAT 是一种网络协议。它将数据从服务器（Roon Core）传送到设备（例如，在最纯粹的 情况下）——网络 DAC。当我们在这里比较时钟相关性时，我们是将苹果与其他网络协议 进行比较——其中许多协议使计算机的时钟以 RAAT 避免的方式成为音频链的固有部分。 当您开始插入附加元件（USB、S/PDIF 发生器、“USB 时钟恢复器”或其他任何元件）时 ，批判性、彻底且具体地思考每个方面的工作原理非常重要。这些考虑因素完全独立於 RAAT，并且是其他系统的特徵。RAAT 不会将其手指伸向 USB DAC，也不会从根本上改变 USB 的工作方式。 在这种情况下讨论时钟和相关概念最令人沮丧的事情之一是它非常复杂，并且存在挥手、 滥用或混淆术语的倾向。许多人从营销来源获取信息，有时这些营销来源对技术细节的处 理又快又松。 例如，在您的问题中，您正在谈论以完全不同的方式影响系统的各种时钟，并认为也许我 们对一种时钟的讨论也适用於其他时钟。这种混乱部分是你们造成的，部分是我们造成的 ，但它很好地代表了总体情况。 ／ 关於 DAC 时钟中的抖动如何只会在数模转换期间导致失真，有一个相对容易理解的概念 。我经常看到这种解释被错误地应用於 USB 时钟恢复器和其他增强产品。这并不是说所 有时钟都没有可测量的抖动，或者这些测量结果无法改进，只是它们的抖动数并不通过相 同的机制与声音质量相关。 根据 USB 规范，接收设备不应该关心这些差异，只要它们在规范范围内即可。如果USB设 备需要计算机生成远远超出USB规范要求的USB信号才能实现其全部性能，那麽设备设计人 员真的完成了工作吗？ ※ Ｑ：这好像是@加斯曼的问题仍然没有答案，除非已经给出的答案相当於：“也许，但前提是 这些辅助设备允许 Roon 访问修改後的/新的 DAC 时钟信号。” 这是一个公平的总结吗@ 布莱恩？ 这个总结就是我上面警告的那种混乱的一个例子。 如果您仔细考虑这些设备的实现细节（如果您还没有，请阅读并充分消化我在上面发布的 John Swenson 的链接，该链接解释了一种此类产品并为进一步理解提供了一个良好的框 架），很明显这些设备是在低级别代理 USB 数据包，而不是 USB 音频协议本身。 这意味着无需考虑“授予访问权限”或“干扰”。Roon 通过这些设备查看 DAC 的时钟， 就像通过任何其他 USB 集线器一样。 100% 明确：此类设备中完成的时钟恢复与音频时钟无关。它们在不与音频播放或音频采样 时钟同步耦合的层中对 USB 数据传输位进行时钟恢复。 Ｑ：我想就是这样@加斯曼的问题是：Roon 使用 DAC 时钟信号将音频流拉至网络音频适配器 时会忽略单独的时钟或其他 USB 增强功能吗？既然答案似乎是“也许”，也许你们可以 指出一些这样的“增强”产品，它们能够为 Roon 提供增强的时钟信号以用作参考时钟？ 也许在此类产品中寻找特定的功能/技术可以帮助我们确定它们是否被 Roon 忽略？ 之所以@加斯曼的问题没有得到明确的答案是因为它使用“时钟”这个词的方式比他引用 的我最初的陈述更不精确，这造成了歧义。我说的是采样时钟，它不属於这些 USB 增强 器产品的范围。 这就是为什麽我开始解释系统中的一些不同时钟，而不是直接回答一个令人困惑的问题。 “为 Roon 提供增强时钟信号以用作参考时钟”的想法完全没有意义。这东西不是这样工 作的。如果 USB/数据传输时钟和音频时钟的概念混淆在一起，就不可能对此进行清晰的 讨论。 ※ Ｑ：似乎即使在最简单的 PC 音频链中，在任何给定时刻都有许多“时钟”在运行，而不仅仅 是 DAC 中的时钟 这是事实，事实上，在许多 DAC 中，根据产品的设计及其功能集运行多个时钟。例如， 具有集成流卡的 DAC 将具有管理 DAC 本身的时钟（或多个时钟）以及在流卡上运行处理 器的单独时钟（或多个时钟）。 Ｑ：人们可以合理地假设，从理论上和可测量上来说，其中任何一个“更好”（更准确，噪音 更少），数字音乐的解码和播放就会“更好”，甚至可能是可听的 然而，这并不完全正确。RAAT 的运行级别高於网络硬件本身。为了大大简化事情，它在 核心上分配一个缓冲区，在端点上分配另一个缓冲区。端点缓冲区可以位於连接的计算机 、流媒体卡等中。核心将数据放入其本地缓冲区，DAC 使用任何适当的接口从其本地缓冲 区中提取数据。核心仅看到其本地缓冲区，DAC 也仅看到其本地缓冲区。由 RAAT 协议来 管理两个缓冲区之间的数据传输，并确保两个缓冲区都不会太空或太满。 为什麽这很重要？ 嗯，DAC 只能从本地缓冲区提取数据，因此它不关心上游管道。核心只能将数据放入其本 地缓冲区，因为它不关心下游管道。 RAAT 管理两者之间的数据传输，为了确保从核心到 DAC 的所有位完好无损，它使用网络 本身提供的较低级别的设施来确保完整性。如果数据包丢失，则会发送新的数据包并按正 确的顺序放入缓冲区。腐败？一样。在大多数情况下，缓冲区足够大，以便在 DAC 不耗 尽数据或内核填满其缓冲区的情况下进行纠错过程。 请记住，我在这里非常谨慎地使用“数据”一词，因为这就是此时的音乐。它是一个位流 ，是正在播放的文件的副本。这是一个异步过程，对 DAC 的模拟输出没有影响。RAAT（ 和网络堆栈）正在促进核心和端点之间的非常聊天的对话。他们确保文件（不超过缓冲区 的大小）从核心复制到端点。 传输介质上使用的时钟对 DAC 发出的声音的影响为零，因为 DAC 所做的所有操作都是从 本地内存缓冲区播放。它不知道，也不关心这些位在进入缓冲区之前发生了什麽。如果交 换机或网络接口中的时钟满足传输机制的规范，则数据传输过程几乎不会出现任何问题。 如果他们不这样做，那麽就会出现更大的问题。 这是一个异步过程。根据定义，传输过程的计时（时钟）与解码过程完全分开。缓冲区将 以可变速率填充和清空，但只要 DAC 缓冲区中有足够的空间，播放就会可靠地继续。 这里区分的关键是数据和信号之间的区别。正在播放的文件不会变成信号，直到其位实时 通过 DAC 。在从 DAC（或端点）的本地缓冲区中提取这些位之前，这些位与用於文档、 图像甚至本文的位没有什麽不同。 我理解发烧友不断尝试“改进”事物的愿望，而这种行为确实是这种爱好的基础。这在过 去更容易做到，因为大多数与物理和变化相关的概念不仅很容易被证明，而且可以用一些 逻辑解释来支持。数字根本不是这样，因为许多概念是反直觉的，而且解释要复杂得多。 如果将流媒体混入其中，问题就会变得更糟。大多数音频设备制造商对网络如何运作以及 网络可能或可能不会对实际播放产生影响几乎不了解。可悲的是，这对那些花费辛苦赚来 的钱来解决实际上不存在的问题的消费者产生了负面影响。 ※ Ｑ：根据您的描述，通过将核心和播放器放在同一设备（NAS 上的文件）中从等式中删除 RAAT 是否会对 SQ 产生任何影响？ 理论上，只要 DAC 手头上有足够的数据来以适当的速率执行解码，数据缓冲区的维护方 式就不会有什麽影响。问题是，当您不控制所有变量时，将缓冲区保持在适当的水平实际 上是非常困难的。 ／ 为了维护系统，您需要主动监控和调整龙头上的阀门以维持填充率，以确保永远不会让水 位低於设定的最低水平。您还需要确保进行调整以确保不会超过安全最大值。您需要对高 水位线和低水位线进行预测，并对通过龙头可用的水量变化和实际排水率的微小变化做出 反应。 这就是 RAAT 正在做的事情。它对 DAC（排水管）的时钟速率进行建模，以了解浴缸是如 何被清空的。它还对网络性能做出响应，以确保填充率不会允许缓冲区溢出或不足。 它甚至比这更复杂，因为核心侧还有一个桶，通过网络“排出”到 DAC 侧的桶，并且桶 的大小根据所涉及的采样率而不同。 现在想像一下对区域进行分组是多麽复杂（特别是如果每个区域有不同的采样率要求）。 区域浴缸需要以绝对锁定的步骤排水才能使其工作，但您无法控制连接浴缸的管道！ Ｑ：或者在正常运行的网络环境中，RAAT 是否足够高效以保持所有缓冲区处於满状态？ 宾果，关键确实是一个正常运行的网络环境。这并不意味着具有数据中心质量或无限带宽 ，而是足以满足在任何给定时间传输音频数据以及任何其他用途的需求。这也不意味着您 需要一堆调整设备和适配器才能使其听起来更好。它只需要满足标准，而且这并不难实现 （尽管许多与音频相关的网络东西[电缆、滤波器、时钟器等]几乎忽略了标准）。 请记住，与典型的千兆位链路（即使是非常糟糕的链路）上的可用带宽相比，音频比特率 根本不算什麽。DXD 约为 20Mbit/秒。DSD512 约为 45Mbit/秒。千兆以太网是 1000Mbit/秒！ 只要网络可靠并且能够处理数据速率，那麽 RAAT 就可以工作（而且效果非常好）。去掉 可靠性，它就会开始变得丑陋。 ※ Brian 提到了时钟质量与一致性，并指出他的帖子中的讨论与後者相关。大多数发烧友对 时钟的讨论都与时钟质量（精度）有关，因为这会影响 DAC 的运行速率。这里的问题是 ，许多人看到“时钟”并假设讨论与抖动或其他一些可听的东西有关。事实并非如此。 时钟质量涉及时钟的准确性，即对於任何给定的时钟“滴答声”，後续的“滴答声”是否 恰好在正确的时间发生，或者是有点早或晚了。过早或过晚都可能会造成不良影响，因为 它会对 DAC 输出的模拟信号产生潜在的听觉影响。 RAAT 根本不处理这个问题。 时钟一致性处理两个或多个时钟之间的差异（如果同时启动并随着时间的推移进行观察） 。在完美的世界中，您可以并排放置两个相同的时钟，在 time=0 时启动它们，并观察它 们永远保持彼此同步。在现实世界中，这不会发生。曾经。这两个时钟可能非常非常接近 ，但它们之间总会有一些偏差。（这是因为时钟始终基於对物理现象的观察，物理系统的 微小差异总是会导致测量结果的差异）。 对於数字音频来说，这种漂移可能是无关紧要的，而且在许多情况下确实如此。如果漂移 （无论是总漂移还是样本间漂移（抖动））足够小，则不会存在於对音频有任何影响的频 率上。 出於数据管理的目的，这是一个大问题。 对於 DAC，输出是开放式的，因为它可以运行得慢或快，并且输入的位将使其作为模拟信 号输出。由於与时钟相关的异常，信号可能会失真，但没有什麽可以阻止 DAC 从一侧获 取比特并在另一侧输出模拟。 当您谈论在缓冲区之间移动数据时，您正在处理一个完全封闭的系统。假设您有两个缓冲 区（A 和 B），每个缓冲区都由单独的时钟（cA 和 cB）控制。数据以 cA 定义的速率移 出缓冲区 A，缓冲区 B 和 cB 也以相同的速率移出。在这种情况下，缓冲器 B 为 DAC 的输入供电，而 cB 则管理 B 的漏极以及 DAC 本身。 这两个缓冲区具有已定义的大小，并且出於实际目的应保持尽可能合理的小。 现在，假设两个时钟频率相同，让该系统开始运行。对於从 A 复制到 B 的每个样本，还 应该有一个样本从 B 移动到 DAC。如果两个时钟完全一致（彼此同步），那麽这工作得 很好并且没有问题。这在现实世界中永远不会发生。其中一个时钟总是比另一个时钟快， 如果允许系统运行足够长的时间，那麽就会发生以下两件事之一。 如果时钟 A 很快，那麽 B 的填充速度将快於耗尽速度，最终将被填满。装满後，您必须 弄清楚如何处理下一个样品。 如果时钟 B 很快，那麽 B 的清空速度将快於其填充速度，DAC 最终将耗尽数据。 处理时钟一致性试图以最有效的方式解决这个问题，使得 B 永远不会被填满或完全清空 。这就是 RAAT 正在解决的问题，您会注意到它与时钟质量无关，而时钟质量正是发烧友 在谈论抖动时所关心的问题。 在像 Roon 这样的系统中，有数十个（或数百个）缓冲区在运行，所有缓冲区都由不同的 时钟驱动。为了确保 DAC 旁边的缓冲区永远不会耗尽数据或溢出，RAAT 需要观察控制该 缓冲区的时钟。在某些情况下，这根本无法做到，因此 RAAT 需要监视尽可能靠近 DAC 的缓冲区。 如果 Roon 可以对远处缓冲区的行为进行建模，那麽就可以确保它始终以不会允许其溢出 或耗尽的速率发送数据。 ※ -- 人间五十年、化天のうちを比ぶれば、梦幻の如くなり ^,,,^ 一度生を享け、灭せぬもののあるべきか (ミ‵ω′)\m/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.36.215.60 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Audiophile/M.1689079757.A.F41.html 我截出来的也是 Brian Luczkiewicz | Roon Labs Founder 跟另名员工所言 看完整串应该能理解，系统时钟应该只跟维持 Buffer 吞吐有关 只要 Buffer 不欠载不溢出＆网路传输是正常的，是不会影响音质 这个真的不重要 处理 Buffer 只要「来的及」，都不是问题 就像原文中也提到 Roon 网路是用 TCP 而不是一般串流常用的 UDP 所以就算封包出现错误也只要重传就好（TCP 特性） 只要在 Buffer 耗尽前重传成功，就不会出问题 #1aMUsw3K (Audiophile) [ptt.cc] Re: [闲聊] PC讯源杂讯解法 https://webptt.com/cn.aspx?n=bbs/Audiophile/M.1683615162.A.0D4.html 可以参考这篇的内容 然後就上面的回答 Roon 默认使用填充／删除样本，而非 Async SRC 来解决样本多或少的状况 Mac 的 Drift Correction 我上面贴的那篇也有提到 弥补的也只是 Audio device 间的 Audio clock 差异 跟 System clock 无关 就像这页里的第一个图 https://support.apple.com/en-us/HT202000 Clock Source 能选系统时钟吗？只有 Audio device 能选不是吗 传输介质上使用的时钟对 DAC 发出的声音的影响为零， 因为 DAC 所做的所有操作都是从本地内存缓冲区播放。 这句是 Roon 的粗暴说法 不是，那个 Clock Source 是在选一台 Audio device 来当 Master Clock 其它 Audio device 的 Audio data 会依样本数偏移来 ASRC 不需要我的回答，人微言轻 建议您直接上 Roon community 发问 看 Brian | Roon Labs Founder 会有何回应 下次 Roon 改版就内建了 盲测不科学啦 其实不用测，因为只要感觉对了就是对 有感这种东西是不需要实测跟量化的 嗯，不好说 但数位厚... 但有感了，当这个结果是事实 什麽原因造成还很重要吗 就算是听觉性因素影响，久了也会腻、麻痹、感情变淡想要换换啊 就像贴了个贴纸、还是点了个灯，看了就觉得好听那就是有效投资 这都能钓出些萌新 旁边坐个志玲姐姐用什麽听都好听 你说一切都是幻觉？实际上根本没差？ 没错、当然是幻觉 志玲姐姐怎麽可能坐在我家 这我过去也提过很多遍，听我说不如听专家说 但这也并不代表类比电气特性不会透过介质串到其它设备就是了 不过有时就算专家说也无法憾动烧友不断尝试“改进”事物的信念 有感就好捏 听了有感跟要佐证您的假设正确是不同的事 就像上面您提到 Drift Correction 跟系统时间有直接关系 说实作一次，去观察 drift correction 的动作? 如何观察到 Drift Correction 跟系统时间有直接关系？ 是有什麽设备可以侦测还是反组译看程式码？或只是我感觉？ 坦白说 Drift Correction 的运作原理网上很多资料，也没什好辩的 实际上我也用过，但不再用的原因跟 Roon 上面的说法一样 除非是後制商品卖钱，不然在 Replay 使用开销太大得之过少不如放给它错 If it can go wrong, it will. 但这个 Wrong 不太痛也很少发生 就放它很偶尔发生，而不是把没问题的也全都整一遍 ※ Reference Mark 还不够清楚吗:D Roon 原始讨论串 system clock 只出现一次 而且後面 Roon 员工一直强调讨论中的此 clock 非彼 clock 全文完全没出现过 Data/Time 相关 依前後文这个 The system clock 也根本跟「真实时间」无关 要怎麽证明校时与音质有直接关联应该不用家访 因为就算家访这两者间的关联还是无法以科学论述验证啊 我会建议有空要去看原文 我个人觉得最大的问题在 您看到 Roon 讨论串中出现了 system clock 一次 就无限放大 system clock 的可能性 而没通盘看完、与理解整个讨论串中 Roon 试图解释的东西 基本上写程式尤其低阶 I/F、I/O，没事不会去用到真实时间 都吗读计时器的 count 或用 10ns、100ms 这些相对时间 要知道现在几点几分几秒需要更多换算 真实时间在电脑系统里是拿来「给人看」的 这不是只是 Roon 的说法，只是 Roon 在相关讨论中满完整的梳理了一番 相关内容其实也在本版与友版中分散出现无数次 光我个人就提过很多次相关内容 只是 Roon 做为业界翘楚，说出来更有份量 其实这些「很小的」时间波动，会被 Buffer cover 也就是 Roon 讨论中提到的半满 Buffer，既有库存、也有空间 所以传输过程中的时钟精度并不十分重要，只要 Buffer 配置得当 AES67 有定义精度吗？若有是多少？若无不就表示不是很重要吗 1 ms 等於 1,000,000 ns 您是说 100ns 的变化会影响 1ms buffer 的稳定度？ 我个人感觉就算是 100μs 都不太会 但很不幸的是，人耳对时间差并不太灵敏 就像一般评延迟感知是用 10ms，超过明显能感到有延迟 部分人比较敏感的也不过几 ms，几 μs 是不可能更别说到 ns 的差异 就像一个 20 kHz 的声波走的的时间是 0.05ms or 50μs 人耳分析频率无法太精细，有点像 FFT 是以一段时间开窗分析窗内的所有频率 所以几 ms 内的声音是分不出前後差异的 数位电子电路的时间，是用晶振振动次数 count 计数出来的.... 没有晶振，没有时间，连 CPU 都不会动了 是，因为时间是用晶振算出来的 就像 Roon 的回应，不是不需要时间，而是时间没这麽关键到精度几 μs DAC 外的任何时钟的品质，不需要过度担心 关键确实是一个正常运行的网络环境 就像 Roon 所说的拿去用在 DAC ，适材适所 晶振是系统时钟的机心，一体两面 以数位电子与程式设计的观点，系统时钟＝晶振＋计数器 校时程式能做的除对时外，是重新计算时间单位需要多少计数 但依 Roon 讨论串这段的时间精度并不需要太过计较 另外回到 e大的想法，我会切成两个独立议题 一个是一般家用户，尤其是没有多区域同步播放需求及AES67 or Dante 多声道 这个校时无关紧要 有多区域同步播放、AES67 or Dante 多声道我不熟 但依上面 s大的回应，Protocol 应该有解决同步问题 不需要额外的处理才是 过去 e大的发文中我好像也回应过 AES67、Dante 是很难走入一般家庭中的 一般家庭中就算是透过区网串流，也没什麽人会碰到需要同步的问题 因为音乐就你丢我收，收到就放 最多 AV 嘴型同步，但这也跟系统时间不太有直接连接 异步，就是各自为政，在规范内照自己的步调走 AD/DA 同时有的状况，一般是在专业录音或现场直播 可有主时钟、或 Drift Correction、或用放删除插入等策略，看选择 ※ 编辑: Oswyn (220.136.195.49 台湾), 07/14/2023 14:04:31