智能家居的智能音频（2021）

# 智能家居中的智能音频 来源：https://computer.rip/2021-11-06-smart-audio-for-the-smart-home.html 阅读格式：[PDF](https://computer.rip/2021-11-06-smart-audio-for-the-smart-home.pdf)、[纯文本](https://computer.rip/2021-11-06-smart-audio-for-the-smart-home.txt) Sonos 提供了一系列基于 WiFi 的网络音箱，本质上是一套面向消费者的分布式音频系统。这是对已在大型建筑背景音乐/公共广播领域以及越来越多娱乐场所和剧场扩声领域普及的网络音频渲染系统的一次（相对）平价且易用的改造。其核心思路是：不再通过昂贵且在商用场景下有损、或在消费场景下难以布线的喇叭线缆从一个放大器位置向多个音箱分配音频，而是将音频通过 IP 网络分配到与每个音箱就近部署的小型放大器中[1]。 这并非新概念，尽管 Sonos 确实在让这一方案在不可靠且变化多端的消费级 WiFi 网络上可靠运行（无明显同步问题）方面投入了大量精力。从商用音频的角度看，它不过是 Dante 或 Q-LAN 的一个更亲民的版本。从消费音频的角度看，它要么是革命性的产品，要么就是二十年来网络化消费级 AV 系统努力的可悲余影。在付出所有努力、历经所有本可能成功的技术之后，我们最终得到的是 Sonos：一个功能不完整、封闭花园式的 DLNA 仿制品。 是的，我对 Sonos 不太公平。Sonos 解决的最大难题——在没有 PTP 等特殊网络设施的情况下实现音频渲染器的精确可靠同步——并不是 DLNA 试图解决的问题。而且这至今仍是一个难题；就连我全新的蓝牙耳机也经常出现不同步的情况，当手机那平庸的蓝牙协议栈跟不上时（也许我那台老旧的手机比理论上的复杂性更该为此负责）。 但每当我真正审视当今的家庭媒体流传输与管理格局——基本上被 Sonos、Apple 的 AirPlay 和 Google 的 ChromeCast 所主导——很难不将其视为 DLNA 的影子。 那么 DLNA 到底是什么，又为什么失败了？更广泛地说，为什么从 90 年代末到 00 年代的所有家庭网络 AV 项目都无疾而终，最终被单薄的、厂商锁定的"投射"协议所取代？ 答案当然是微软和资本主义（这两个家伙凑在一起很少有好兆头）。但我们慢慢道来，从 90 年代末不断演变的家庭媒体格局说起。 CD（compact disc，光盘）在 80 年代末开始广泛流行，代表着音乐分发方式的巨大变革。除了低成本、小体积和出色音质之外，CD 还是第一种广泛普及的消费级数字音频记录格式。第一次，在理论上可以创建 CD 的精确数字副本。一旦写入另一个存储设备，CD 就可以作为计算机数据来处理[2]。 "CD 抓轨"（Ripping）实际上直到 00 年代初才变得较为普遍。在实践中，从 PC 上"抓取"音频 CD 相当复杂，因为 PATA CD 驱动器的架构出人意料地古老。90 年代早期的计算机往往无法以足够快的 I/O 速度以 1x 速度（即与音频比特率相同的速度，可实现实时解码）读取音频 CD。即使可以，音频 CD 的数据量也有数百 MB，而如此大的硬盘当时非常昂贵。因此，PC 的 CD 光驱播放音频 CD 时就像一台普通的 CD 播放器，输出模拟音频。有些人可能还记得安装 IDE 光驱时需要将光驱的三线模拟音频输出连接到声卡。有些人甚至还记得那些在前面板上带有独立播放控制按钮的较少见的 CD 光驱，可以在没有任何媒体软件控制的情况下播放音乐。 这些 CD 光驱在播放音频时的行为很像智能手机打电话：计算机实际上完全"不在回路中"，它所做的只是向 CD 光驱发送播放/暂停等命令，由 CD 光驱在内部解码音频并将其转换为模拟信号，直接发送到声卡中的放大器。在这种架构下，"抓取" CD 的方式实际上是告诉 CD 光驱开始播放，然后用声卡录制其模拟输出。这只能以实时速度运行，并非所有声卡都能在没有外部跳线将线路输出连接到线路输入的情况下完成，而且双重转换降低了音质。这种方法没有流行起来，尽管 GNOME 的 Sound Juicer 直到 2005 年左右仍在使用这种方法。 更好的方法——真正将 CD 作为数据读取、在软件中解码音频——在 00 年代开始流行，主要形式是 WinAmp 5.0 和 Windows XP 中的 Windows Media Player。这大大加速了一个在业界看来已经很清晰的趋势：消费者将在实体介质上购买音乐（在当时大多数消费者的互联网连接上下载仍然不可行），但在未来他们会立即抓取、存储在中央设备上，然后使用各种设备以数字形式回放。 微软大力押注这个未来愿景，多少因为这意味着现代家庭音响系统中需要多份 Windows 授权副本。一个涉及添加多个新操作系统功能的重大开发项目促成了 Windows XP Media Center Edition（MCE）的发布，时间是 2002 年。MCE 在当时是一套令人印象深刻的软件。MCE 电脑不仅仅是一台电脑，它是一个"家庭媒体中心"，能够消费多种格式的媒体、存储它们，然后通过网络流式传输到多个设备。MCE 让消费者见识了"电脑"在媒体领域角色的重大拓展。例如，MCE 支持有线电视的播放和录制，多家 OEM 厂商销售预装有线电视调谐器的 MCE 台式机。一台 XP MCE 机器可以与 Tivo 竞争，而且拥有 Tivo 直到后来才推出的分布式回放功能。 微软利用其在家庭影院领域的新阵地——Xbox——围绕这一平台打造生态系统。初代 Xbox 主机经过购买升级后以及所有 Xbox 360 主机都可以充当"媒体中心扩展器"（media center extenders），这需要打开一个 RDP 会话连接到 MCE 机器，在 Xbox 上呈现 MCE 界面。为支持此功能而实施的 RDP 扩展——即通过 RDP 高效流式传输 HD 视频而无需重新编码——后来推动了 Windows Vista 与各种支持以太网的投影仪之间的"网络投影仪"功能。可以说这是现代 ChromeCast 的主要前身，因为 RDP 引入了一些（但远非全部）向流媒体目标卸载计算的能力，而这正是 ChromeCast 所依赖的。事实上，Media Center Extender 和网络投影仪在技术上密切相关，在二者都已归于沉寂这一点上也是如此。现代"网络投影仪"通常依赖更简单的、类似 AirPlay 的、由微软支持但开放的 Miracast 协议[3]。 由于 Media Center Extender 依赖于 RDP，它本质上要求扩展器实现 Windows 图形栈的相当大一部分（记住 RDP 基本上是 Citrix 早期应用流传输工作的标准化，它做了大量假设——一个 Windows 客户端连接到 Citrix/Windows 服务器环境，并将大部分绘制工作卸载到客户端）。这对运行 Windows 的 Xbox 来说没有问题，但使非 Windows RDP 客户端在今天变得实用的 RDP 改进和开放标准在 00 年代尚未完成，指望传统的消费级 AV 制造商实现扩展器功能也不现实。不过微软并未推出完整的产品线，因此它需要某种生态系统。 巧的是，Intel 恰好也在关注完全相同的问题，已经开始推出一系列 Intel 品牌的媒体流传输解决方案（包括 WiDi——在现实中亲眼见到简直就是看到独角兽——它允许某些 Intel WiFi 适配器在流媒体视频到电视成为常见消费功能之前很久就能做到这一点）。由于媒体流传输需要快速 I/O 和网卡（都是 Intel 的产品），这确实有潜力扩大消费者对 Intel 当时商用产品的兴趣。Intel 发起并招募了微软和消费级 AV 巨头 Sony，成立了一个名为 Digital Living Network Alliance 的新组织。这就是 DLNA。 DLNA 基于 UPnP（当时领先的消费级网络自动发现和自动配置协议），为新型集成家庭媒体网络定义了一套网络标准。DLNA 定义了被大致归类为媒体服务器（Media Server）、媒体播放器（Media Player）和媒体渲染器（Media Renderer）的一组设备如何相互发现并交换信令，以建立各种类型的实时媒体流并执行远程控制。大致来说，媒体服务器使用 RTSP 等既定协议向网络提供一种或多种类型的存储媒体（例如磁盘上的文件）或实时媒体（例如有线电视调谐器）。媒体播放器允许用户浏览任何可用媒体服务器的内容并控制回放。媒体渲染器从媒体服务器接收媒体并解码后进行回放。 媒体播放器和媒体渲染器的分离可能看起来有点奇怪，在实践中它们通常是同一产品的两个功能，但这实现了我们在 Spotify Connect 中看到的那种基于网络的远程控制。也就是说，你可以在电脑上启动一个媒体播放器（比如 Windows Media Player），用它来在集成到你的立体声接收器中的媒体渲染器上播放音频。其他媒体播放器也可以发现该渲染器并控制其回放。这一切在 Windows XP 中都可行，但由于媒体渲染器太少，实际上很少被使用。 问题不一定是 DLNA 没能催生一个生态系统。虽然微软通过 MCE、Windows Media Player 和资源管理器（在那里它与 Homegroup 对等网络共享系统交织在一起）为 Windows 添加了相当完整的 DLNA 支持，但 JRiver 和 TwonkyMedia 是重要的第三方商业 DLNA 媒体服务器。在开源方面，Xbox Media Center（XBMC，现名 Kodi）拥有相当强的 DLNA 支持。Plex——今天仍然是一个相当流行的家庭媒体系统——最初是 XBMC 的移植和增强版，后来获得了更加完整的 DLNA 支持。甚至 Windows Media Center 本身也可由第三方扩展，提供公共 API 以向 MCE 界面添加应用程序和功能。 几年前，大约 2008 年，我成功地通过 DLNA 实现了 TwonkyMedia、Plex、Windows Media Player 和 Logitech 硬件渲染器的互操作。随着时间推移，这变得越来越困难，因为支持 DLNA 的硬件市场不断萎缩，DLNA 的软件支持也已停止维护。 DLNA 面临的一个重大挑战是消费者对完全数字化家庭媒体的接受程度很低。消费者尚未习惯"智能电视"和其他将集成 DLNA 客户端的设备这一概念，这是一个显而易见的问题。DLNA 客户端在 HD-DVD 和 Blu-Ray 播放器等设备中有些常见（这些设备本来就需要相当庞大的软件栈，因此添加 DLNA 客户端并不需要太多额外工作），但它往往是一个二等公民功能，营销极少，实现也通常极为敷衍。我记得某款 LG Blu-Ray 播放器有一个基本功能完整的 DLNA 媒体播放器和媒体渲染器，但实际上几乎播不了任何东西，因为在芯片组和 802.11g 之间的某个环节，网络流传输性能太差，无法跟上 1080p 内容的需求。 而 802.11g 也是问题的一部分。00 年代中前期的家庭网络出人意料地糟糕。我想这不应该太令人惊讶，因为"家庭网络"在那个时期基本上还是一个新概念，正在取代直接连接到调制解调器的单台电脑。宽带正在城市中普及，但 DOCSIS 和 DSL 调制解调器仍然提供 USB 接口，人们使用它并不罕见。几乎没人布设以太网，因为隐藏布线的成本很高，而沿着踢脚线走线既令人沮丧又影响美观[4]。802.11g 是当时的主流 WiFi 标准，名义上足以应付各种媒体流传输，但实际上拥塞和范围问题使得 802.11g 的性能在大多数时候相当糟糕。以上这些情况在今天很大程度上仍然成立，但 WiFi 名义速度已从 54mbps 提升到远超 1Gbps，即使在真实环境中经历*非常*显著的性能下降后仍能提供稳定的 20mbps。 然而最大的问题，是家庭中"服务器"这个令人头疼的概念。微软当时的假设是，一台台式电脑将充当媒体服务器。事实上，MCE 专门引入了 Windows XP 的电源管理增强功能，旨在让 MCE 机器保持在待机模式下，但在需要媒体录制或流传输时唤醒（这似乎从来就没有很好地工作过）。微软通过其 MCE 营销策略进一步强化了这一概念——MCE 仅向开发者和 OEM 发布，不能作为普通独立许可证购买。如果你要用 MCE，那就得在一台作为工作站和媒体服务器混合体的台式机上使用。 不幸的是，在大致相同的时间段内，家用台式电脑开始变得不那么常见。笔记本电脑价格更低、性能更好，可以腾出桌面空间并增加大量灵活性，而消费者对购买中塔式机箱也越来越缺乏热情。而且，当时的硬盘容量使得普通台式电脑作为媒体服务器有些局限。记住，那还是实体介质的尴尬时期，台式电脑拥有*两个*光驱是很常见的——人们想要一个 DVD 播放器和一个 CD 刻录机，而还没有人想出如何经济地将两者整合到一个设备中。硬盘通常只有几百 GB。 看起来需要的是某种家庭媒体服务器设备——紧凑、平价、足够用户友好，以至于人们会像对待路由器/AP 一体机这样的典型网络设备一样对待它。Apple 在 AirPort Time Capsule 上大致做到了这一点（后来在 Apple TV 上也有点像，不过情况变得有些混乱），这差不多就是我们今天所说的消费级 NAS（比如 Drobo 或 QNAP 之类的）。在 00 年代中期，这两种选择在市场上都不存在，大多数人也不会去观看那一期关于如何经济地将 JBOD 连接到台式电脑的 Screen Savers 节目。所以，2007 年，微软端出了一道真正的新奇之物：Windows Home Server。 Windows Home Server 是 Windows Server 2003 R2 的一个精简版（虽然精简得并不多），旨在让消费者通过一个名为 Windows Home Server Console 的桌面客户端轻松设置和管理。Console 在原理上有点像 MMC，但功能更少、向导更多。虽然我很难确认这一点，但我认为它实际上是通过使用 Virtual App 技术的 RDP 工作的，意味着实际的 Console 运行在服务器上，只有 GUI 绘制发生在客户端上。这可能简化了实现，但结果是