融合正在挑战广播企业安排广播节目，互操作及与世界其它其余地方联系的方式。
广播正越来越多媒体、交互和协作。与此同时，基于AV/IT的广播系统正在利用无处不在的IP—电信业的骨干。
随着IP音频编解码进入广播设备市场，像欧广联(EBU)这样的技术委员会接近完成IP上音频采集(ACIP)互操作性标准和操作规程建议。
未来的基于IP音频网络结构将需要一种新方案，向广播工程师提出了一种多种挑战。
背景
来自电信业的同步链路长期以来为广播机构提供传统的音频传输。它们是向发射机和播音室提供全双工链路的一种可靠和有保证的方式。
由于成本的考虑以及新ISDN线路供应越来越困难，采用基于包的异步网络和IP的发展趋势获得了动力。
在音频编码、传输协议、话路信令及管理IP网络故障的策略方面有许多工作。一个主要的考虑是正确地设计一个能处理广播质量音频，有让人满意的服务质量（QoS）的IP网络。
IP编解码结合音频数据压缩和IP分包—IP包的结构。此包包括有效载荷（音频取样或帧）和包头。
用户数据报上的实时传输协议（RTP）可以提供一个低延迟，假定包长度和网络QoS得到细心管理，对PCM音频的延迟低于10ms。
虽然广播音频传输转用IP网络极有前途，但不幸的是大部分IP音频编解码系统仅仅提供传统点对点同步音频编解码的功能替换，尽管在一个不同的传输级。这种方案没有利用软件控制的IT网络的灵活性和可扩展性。
什么是NAOS？
网络音频操作系统（NAOS）背后的概念是为广播音频软件开发者提供一种建立数字广播基础结构的服务框架。
像Digigram visiblu这样的NAOS用一种分布式的IP音频处理和路由分配系统方案，和其它数字音频传输形式一道管理IP音频流。
对于软件工程师，它提供了管理一能收发IP音频流的PC平台集合体的图形编程界面。
主要推动力是充分利用CUP的能力及标准PC平台或运行在Windows或Linux的嵌入处理器的网络接口，而不是专有的基于硬件DSP的设计。
总体结构考虑
n个PC平台的集合体实现广域网上多对多音频路由。由于此网络音频操作系统同时管理“平台”和“系统”上的服务，这是可行的。
“平台”是联网的计算机或硬件装置，它有一个NAOS程序，并包含2个逻辑实体：内核和音频引擎。
内核处理平台间的通信，并允许系统内部的聚合。音频引擎基于音频图形的概念，并实现音频传输路由、处理和控制功能。
“系统”是平台的一种集合。一种预订机制允许每个平台都能自我发现，并允许应用程序通过NAOS应用程序接口（API）收发状态数据。
经由NAOS可以远程访问系统，控制音频处理及传输资源在平台上的分配。
内核系统
NAOS最重要的总体结构考虑是一个确保与音频图形复杂性无关的低延迟处理的确定性和优化的环境。
NAOS音频引擎应天生管理多路码流并在主操作系统下（如Windows XP或Linux）以32比特浮点表示处理音频数据，同时使CUP负荷最小。
“内核”实现系统级服务，这包括集合若干个平台到一个系统及在不同平台之间分配系统信息的可能性。
对此系统管理的访问权必须经由加密的登录得到保护，防止音频流路由未经授权的改动。
选择的主控平台（它起指派的“交通警察”的作用）提供由于网络故障而引起的平台损坏检测以及在当前的主控平台出故障时重新选择一个不同的主控平台。
在使命攸关的广播环境，此检测和失效备援是自动出现的，不会丢失音频流样本。
可以提出网络结构的一个摘要，显示每个连接器和码流的状态，作为在配置或监测系统状态时的一种可视化帮助。
连接器、码流
对NAOS起中心作用的另一关键概念是“连接器”和“码流”。“连接器”是一种使用硬件资源（如音频板、NIC或CPU）的处理单元，产生、转换或消耗音频数据。连接器可由码流链接，以便建立音频图形。
源连接器产生音频数据。源连接器的例子是物理音频输入、如EtherSound这样的网络音频通道、经由文件系统的声音文件读取，以及输入IP音频流。
目标连接器消耗音频数据。目标连接器的例子是物理音频输出、网络音频通道、声音文件，以及输出IP音频流。
“效果”连接器转换音频数据。效果连接器的例子是编码器和解码器——如PCM、MPEG和aacPlus。像混音、时标、取样率转换、增益、声像、均衡、动态处理和计量等的效果是可以实现的。
NAOS还能支持用软件开发软件包（SDK）开发的插入处理。
“码流”是两个连接器之间的音频通路。取决于其状态，音频码流被阻断或从一个上游连接器流到下游连接器。码流和连接器允许建立音频图形。
系统内部发生的任何东西都可能是一个通知的主题。在一个典型的广播环境，像音频文件服务器这样的信号源、来自远程播音室的远程IP输入信号及来自正在播出的播音室话筒的实况输入都被解码为像32比特浮点表现这样的公共音频格式。
效果连接器施加像增益、EQ和时间伸展这样的音频处理。目标连接器接着把压缩音频传输到日志文件和STL，而非压缩音频则被发送到播音室监听。分布式音频图管理此处理和每个平台上的I/O资源。
音频引擎
音频引擎是NAOS的一个组成部分，能执行各种操作，如无音频失落的音频图实时动态建立；MPEG编码/解码、混音、淡入淡出、计量和效果应用；广播音频包头解码；音频流控制和事件驱动动作；透明发送任何音频源到任何音频目的地；音频流间的同步，甚至于不同的平台之间；不同音频源之间的偏离管理；音频硬件平台专用的驱动器支持。
至于IP码流管理，此音频引擎遵循标准的UDP上RTP/RTCP协议，支持单播和多播模式及EUB NA/ACIP规定的操作建议。
为达到满足广播音频运营商要求的质量等级，如包抖动管理、包记录管理和包括智能重放在内的包损失管理这样的IP码流服务可作为NAOS内的功能。
在网络连接质量为未知质量或网络为单向性时（卫星IP传输经常是这种情况），前向纠错（FEC）机制是有帮助的。
不过，假如丢失一个包可以保证100%恢复的FEC方案将要求比一个无FEC的RTP音频流多50%的带宽。
NAOS内的IP接收机连接器还具有测量包抖动和损失的能力，因而可动态运用各种取样重放或时间伸展模式，保持一个良好定时的稳定的音频流。
应用
现在的广播链依然包含若干个“井”—从制作演播室、总控、演播室至发射机链路（STL）—以及最后的发射机。 [Page]
尽管广播链内这些要素之间有确定的相互作用，但实际上没有互操作性。例如，坐在播出调音台前的技师与发射站发生的事几乎没有联系。
此外，运行全国性网络的大型广播机构需要管理极其复杂的相互作用，以便分发他们的节目，包括：(1)多个收录的节目；(2)本地化节目；(3)本地化广告插播；(4)音频和元数据传输；(5)远程发射站。
因此，NAOS一个最重要的应用是提供整个广播链统一的、可互操作的和连贯的音频路由。
当然，此需求并非唯一的目标—现有的调音台、矩阵和分配链路很好地各司其职。NAOS必须集成和支持这些系统，并且提供一个通向IT型网络管理的路径。
为支持业务流程和交互媒体，在IP码流中插入标记和元数据的可能性也是非常重要的。标记能触发和同步接收平台上的动作，而包括文字和图像的元数据能描述内容，或为接收显示单元提供另外的内容。
总结
许多IP编解码正在满足一个受管理的IP网络内鲁棒的点对点音频传输的需求。
基于DSP的音频处理和混合及数字音频矩阵还提供传统上支持广播制作和播出业务所要求的控制。
NAOS把这些关键功能集成到一个基于软件的多平台系统，该系统具有在许多标准的PC平台上分配一个图表的能力。
冗余、失效备援机制和供替换的路由发现是支持广播环境中习惯用法的关键特性。NAOS的编程界面允许测量具有资源集成控制、音频路由和网络管理及编解码选择的整个分布式音频系统。
利用在IT行业的研发投资来满足广播机构的需求，NAOS是一种灵活和可扩展的方案，它可以使用一个公共的软件编程框架。
通过组合使用如话路启动协议(SIP)和RTP这样的网络标准，广播电台使用标准PC平台上的软件，能迅速配置和部署高质量音频链路。