Android 多房间音频：设置与同步

多房间到底意味着什么

多房间音频就是在不同房间的音箱上同时播放相同的音乐。从厨房走到客厅，歌曲无缝继续。没有间隙，没有回声，没有房间之间的奇怪延迟。

这就是承诺。每个音箱制造商都把它印在包装盒上。在单一生态系统内——Sonos、Apple、Google——它基本上可以工作。问题从你拥有不同制造商的音箱开始，而这基本上是每个人的情况。

多房间的真正定义不仅仅是”同一首歌在多个地方”。它是同步播放——来自不同音箱的音频在几十毫秒内到达你的耳朵。如果两个音箱相差超过约 50ms，你能听出来。不是回声，而是一种涂抹感，一种厚重感，让人感觉不对。低于 30ms，大多数人分辨不出差别。这就是目标。

同步问题

以下是为什么跨不同设备的同步播放确实很难。

当你点击播放时，一连串事件发生：应用通过 WiFi 向音箱发送命令，音箱接收它，缓冲一些音频数据，通过其 DAC 处理，声音就出来了。每一步都需要时间，每个设备需要不同的时间量。

一个 Chromecast 可能从播放命令到第一个声音需要 800ms。一个 Denon 接收器可能需要 200ms。一个 SoundTouch 音箱大约在 150ms。你手机的耳机插孔？不到 10ms。如果你在同一瞬间向所有四个设备发送播放命令，声音几乎立即从手机出来，Denon 在五分之一秒后，SoundTouch 在那之后，而 Chromecast 在你点击播放后将近一整秒。

这只是启动。一旦播放，设备会漂移。网络抖动给每个命令增加几毫秒的随机性。内部时钟不是完全同步的——一个音箱以 44,099.8 Hz 而非 44,100 Hz 运行，一小时内将漂移约 150ms。某些设备在 WiFi 频道切换时短暂暂停。某些大量缓冲并忽略跳转命令。某些准确报告其播放位置；其他的四舍五入到最近的秒。

这些问题中没有一个单独来看是灾难性的。但在一个充满不同音箱的房子里组合起来，它们会很快累积。

协议格局

当今有四大协议处理多房间音频。每种对同步问题采取不同的方法。

	Sonos	AirPlay 2	Chromecast	UPnP/DLNA
生态系统	仅 Sonos	仅 Apple	仅 Google	开放标准
同步精度	~1ms（专有网状网络）	~5-20ms（Apple 优化）	~50-200ms（Cast 群组）	无原生同步
分组	原生，出色	原生，良好	原生，不错	无分组标准
设备范围	仅 Sonos 音箱	Apple + 授权设备	Cast 兼容	接收器、电视、串流器、音箱——数百个品牌
Android 支持	仅通过 Sonos 应用	不可用	是	是

Sonos 用专有硬件解决同步——他们的音箱形成一个具有微秒级精确时钟同步的网状网络。它是黄金标准，但你被锁定在 Sonos 硬件中。

AirPlay 2 使用 Apple 的时序同步协议来保持音箱同步。它工作得很好，但仅限 Apple。在 Android 上不可用。

Chromecast 群组在 Google 生态系统内工作得相当好。你在 Google Home 中创建音箱群组，Cast 兼容的应用可以针对该群组。同步不错——通常在 50-200ms 内——但系统是封闭的。只有 Cast 兼容设备可以参与。

UPnP/DLNA 是开放标准。它与最广泛的硬件兼容——Denon 接收器、Yamaha 条形音箱、Panasonic 蓝光播放器、WiiM 串流器、智能电视等。但问题是：UPnP 完全没有设备分组或同步播放的概念。规范根本不涉及这个问题。每个渲染器被视为独立设备。

大多数人并不完全生活在一个生态系统中。你有五年前买的接收器、卧室的 Chromecast、客厅的智能电视，也许还有露台上的蓝牙音箱。没有单一协议能覆盖所有这些。

跨协议挑战

这是大多数音乐应用留下的空白。

Spotify Connect 工作得很好——与 Spotify Connect 设备。Google Home 把 Chromecast 分组得很好——但只是 Chromecast。你的 Denon 接收器支持 UPnP 和 AirPlay，但你的 Chromecast 不说 UPnP，你的 Android 手机不说 AirPlay。

那么当你想让厨房的 Chromecast 和客厅的 Denon 接收器同时播放同一首歌时会怎样？在大多数应用中：什么都不会。你选一个设备。另一个房间保持安静。

根本问题是架构性的。大多数应用是围绕单一输出范式构建的——它们向一个目的地发送音频。多房间需要一种根本不同的模型：一个什么在播放的单一真相来源，通过每个设备理解的任何协议向多个目的地分发，然后持续监控和校正所有设备之间的漂移。

我们如何在 Echobox 中构建多房间

我们称之为输出群组。你选择你想要的设备——任何组合的 UPnP 渲染器、Chromecast 设备和你手机自己的输出——Echobox 创建一个群组来协调所有设备间的播放。

核心思想很简单。Echobox 维护一个单一的播放时间线——一个什么曲目在播放、在什么位置的权威记录。当你点击播放时，群组协调器使用每个设备的原生协议向群组中的每个设备分发播放命令：UPnP 渲染器的 SOAP 命令，Chromecast 的 Cast SDK，以及本地音频引擎给你的手机。

让它们大致同时开始是第一个挑战。不同设备有截然不同的启动延迟——一个 Chromecast 可能需要 500ms 来缓冲和开始，而 UPnP 渲染器需要 300ms，本地引擎几乎不需要。所以我们错开播放命令：最慢的设备首先收到命令，然后我们等待，然后发送给下一个最慢的，依此类推。时序使用绝对时钟参考而非累积延迟，所以每个命令的执行时间不会扰乱计划。

我们花了数月才做好漂移校正。第一个版本很糟糕——它会过度校正，造成可听的跳跃，或校正不足，让设备在几分钟内漂移开。

当前系统的工作方式如下：一旦所有设备都在播放，Echobox 大约每秒轮询每个设备的当前播放位置。它将每个设备的报告位置与它应该在的位置进行比较，基于同步锚点——一个将挂钟时间与媒体位置联系起来的参考点。如果一个设备报告它在 1:23.400 但锚点说它应该在 1:23.650，那就是 250ms 的漂移。

接下来发生什么取决于设备。

每设备智能在这里至关重要。Echobox 为它见过的每个设备维护一个配置文件，从三层构建：设备关于自身的宣传、我们对其家族的了解（所有 Denon 接收器行为相似），以及我们在运行时观察到的。跳转可靠的 Denon AVR 获得紧的漂移阈值——我们会在 150ms 漂移时使用跳转命令校正。跳转不可靠的通用 DLNA 电视获得更宽的容忍度——500ms 才标记，如果跳转失败次数太多我们可能完全跳过校正。系统在学习：如果一个设备的跳转命令 70% 的时间失败，Echobox 停止尝试跳转校正该设备并接受更松的同步。参阅我们关于 UPnP 串流的指南了解更多关于设备功能检测的信息。

UPnP 没有原生分组标准，所以我们必须自己构建协调层。群组中的每个 UPnP 渲染器都有自己的 SOAP 命令——SetAVTransportURI、Play、Seek——就好像它是唯一播放的设备。协调层只是确保这些命令以正确的顺序和正确的时序发出。

我们特别自豪的一件事：你的手机可以在本地播放的同时向网络设备串流。本地引擎以不到 10ms 的延迟直接从音频缓冲区读取，而同一曲目通过 HTTP 串流到网络设备。这意味着你可以戴着通过蓝牙连接的耳机走来走去，而房子里的音箱播放同一音乐。本地 Android 音频路径独立处理自己的时序，所以本地播放永远不会被网络协调开销降级。

当设备掉线时——WiFi 中断、音箱进入睡眠——系统不会惊慌。它跟踪连续失败次数，只在五次未命中轮询后才将设备标记为失败。如果它恢复了，三次成功的轮询恢复它。这防止了在网络条件边缘时群组不断切换设备进出。

坦率地说，最困难的部分不是任何单一的技术挑战。而是让系统在那里的设备多样性中可靠地工作。一个制造商的音箱固件更新改变了它们的跳转行为。某些渲染器以整数秒报告位置，这使得亚秒级漂移检测不可能。某些 Chromecast 型号启动需要这么长时间以至于音频开始时它们已经落后整整一秒。每个怪癖都需要自己的解决方案，系统必须优雅地降级而不是完全崩溃。

实用设置提示

网络要求。 所有设备需要在同一子网上。如果你有一个具有独立 IoT 和主网络的 mesh WiFi 系统，你的音箱和手机需要在同一个上。SSDP 组播发现需要工作——一些企业级路由器默认阻止组播。如果 Echobox 找不到你的 UPnP 设备，组播过滤是首先要检查的。

WiFi 稳定性比速度更重要。 多房间音频不需要太多带宽——即使未压缩的 CD 品质音频也只有约 1.4 Mbps。但它需要一致的延迟。如果你的 WiFi 丢包或间歇性拥塞，漂移会比校正系统能补偿的更快地累积。5 GHz 网络通常比 2.4 GHz 提供更一致的延迟，尽管 2.4 GHz 穿墙范围更好。

选择群组设备。 为了最紧的同步，将具有相似特性的设备分组。来自同一制造商的两个 UPnP 接收器比 Chromecast 配 UPnP 电视同步得更好。话虽如此，混合群组也能工作——只是相应设置你的期望。两个 UPnP 串流器可能保持在 50ms 内；一个 Chromecast 加一个 UPnP 渲染器可能稳定在 200ms 左右。

管理延迟预期。 Sonos 等硬件同步系统实现 1-5ms 精度，因为音箱共享时钟。通过 WiFi 的软件协调同步（每个跨协议解决方案都使用的）在最佳情况下上限约 30-50ms。对于背景聆听——做饭或工作时整个房子播放音乐——200ms 以内任何都没问题。只有当你站在两个房间之间的门口时，你才会注意到漂移。

什么时候用什么。 如果你有多个 Chromecast 设备，为它们创建 Google Home 音箱群组比应用级协调更简单，同步也更好。使用 Echobox 群组处理原生分组无法处理的情况：混合 Chromecast 和 UPnP、添加你的手机作为群组成员，或分组完全没有原生分组支持的 UPnP 设备。两种方法不是互斥的——你可以对某些房间使用 Chromecast 群组，对其他房间使用 Echobox 群组。

故障排查。 如果一个设备持续显示高漂移，首先检查其 WiFi 信号强度。弱 WiFi 意味着可变延迟，意味着同步引擎在不断追赶一个移动的目标。如果特定设备在群组中造成问题但单独工作正常，它可能有影响跳转或位置报告的固件怪癖——Echobox 的信号路径诊断会向你展示设备的配置文件，包括其同步适用性评级和关于其行为的学习观察。

现状

跨不同协议的多房间是一个困难的问题，我们不假装它已被完美解决。软件协调同步永远不会在严肃聆听中匹配 Sonos 等硬件同步系统。某些设备有我们尚未遇到的固件怪癖。位置报告精度在制造商之间差异很大。

但对于真实世界的场景——来自不同时代、不同品牌的不同音箱，全部从你的手机同步播放你的音乐库——它确实有效。不是发烧级的同步精度，但足以让全屋聆听真正令人愉快。系统会随时间变得更智能：每次播放会话教会 Echobox 关于每个设备行为的更多信息，为可靠的设备收紧校正，为不稳定的设备放宽校正。