QNX下实现VoIP语音的应用研究

2012-06-25赵付轩杨斌

单片机与嵌入式系统应用 2012年7期

关键词：话音编码器数据包

赵付轩，杨斌

（西南交通大学信息科学与技术学院，成都 610031）

赵付轩（硕士生）、杨斌（教授），主要研究方向为单片机与嵌入式系统应用。

引言

1 嵌入式系统硬件设计

1.1 OMAP3530平台简介

如图1所示，BeagleBoard开发板主要由OMAP3530异构双核处理器、MMC模块、电源、I2C总线模块及多通道缓冲串口（McBSP）等部件组成。系统由MMC模块通过SD卡启动Bootloader及QNX操作系统，通过I2C总线模块连接语音模块，通过McBSP连接其他模块。

图1 BeagleBoard开发板

OMAP3530采用一种独特的双核结构，把控制性较强的ARM处理器和高性能、低功耗的DSP结合起来，是一种开放式的可编程体系结构。对于一些运算量大的实时信号，例如图像、音频数据，可以采用DSP进行计算，而对于通信、外设控制等功能，则采用ARM处理器来实现，从而在功耗和复杂应用之间建立了良好的平衡。利用不同的内核（ARM和DSP）和硬件加速器的不同功能，根据性能或功耗的要求将一个算法映射到最佳的处理器引擎，这样分别发挥了DSP和ARM核的优势，与传统只使用ARM核或只使用DSP芯片的移动终端相比，OMAP成功实现了性能与功耗的最佳组合。

1.2 ARM和DSP核之间的通信

ARM与DSP通信结构框图如图2所示。Codec Engine是连接ARM和DSP或协处理器的桥梁［1］，是介于应用层（ARM侧的应用程序）和信号处理层（DSP侧的算法）之间的软件模块。ARM应用程序调用Codec Engine的 VISA （Video，Image，Speech，Audio）API，如图2中VIDENC＿process（a，b，c）。Codec Engine的stub（ARM侧）会把参数a、b、c以及要调用DSP侧process这个信息打包，通过消息队列（message queue）传递到DSP。Codec Engine的skeleton（DSP侧）会解开这个参数包，把参数a、b、c转换成DSP侧对应的参数x、y、z（比如ARM侧传递的是虚拟地址，而DSP只能认物理地址），DSP侧的server（优先级较低，负责和ARM通信的任务）会根据process这一信息创建一个DSP侧的process（x，y，x）任务最终实现 VIDENC＿process（a，b，c）的操作。

图2 ARM与DSP通信结构框图

1.3 语音采集和播放模块

QSA（QNX Sound Architecture）继承和拥有大部分0.5.2版的高级Linux声音架构（ALSA）的特点。虽然QNX声音架构（QSA）和高级Linux声音架构（ALSA）有很多相似的地方，但是它们并不兼容。在QNX Neutrino 6.5.0中现在支持两个以上声道，并且提供了一种机制，这种机制可以让你配置声音转换器插件以增加或减少声音或声道［2］。QNX声音架构支持各种各样的数据格式。QNX的声音架构分三个层次，从上层的ALSA应用层到中间ALSA内核及驱动层（其中包括编解码器及平台驱动等），再到最底层的OMAP3530的硬件层（包括I2C总线控制接口、系统DMA及 McBSP）。ALSA SoC架构如图3所示。

1.4 操作系统

如图4所示，QNX是一个真正的微内核操作系统［3］。在微内核RTOS中，应用程序、设备驱动程序、文件系统和网络协议栈都驻留在内核外部的独立地址空间，它们与内核以及彼此之间相互隔离，因此该系统具有出色的故障包容性，一个组件的故障不会导致整个系统崩溃。QNX是一个多任务、多用户、分布可嵌入、符合POSIX标准的操作系统。QNX又是一个实时操作系统，它提供用户可控制的、优先级驱动的、基于优先抢占的调度方式。它的自身开销小、上下文切换快，在同样的硬件条件下给实时应用留下更大的余地。

图3 ALSA SoC架构

图4 QNX系统微内核架构

2 VoIP技术

2.1 VoIP基本原理

通过语音的压缩算法对语音数据编码进行压缩处理，然后把这些语音数据按TCP／IP标准进行打包，经过IP网络把数据包送至接收地，再把这些语音数据包串起来，经过解压处理后，恢复成原来的语音信号，从而达到通过网络传送语音的目的。

2.2 VoIP协议

VoIP架构中用到的协议主要有RTP、UDP及IP，语音数据流程如图5所示。

据自然正家的数据统计，在服务过程中换用公司自发研制的清洁套组后，员工的工作效率提升了17%，客户满意率达到98%以上。好品质的清洁套组和高口碑的服务在客户群中口口相传，公司的订单也就越来越多。

图5 语音数据流程

采集的语音通过压缩RTP、UDP及IP打包之后通过局域网进行传输，然后在接收端解IP包，执行相反的过程，最后播放语音。VoIP通道实际上是语音分组、RTP和UDP的通道。它并非一个IP的通道，因为在每个节点上IP协议都被使用。

作为VoIP的设计者，必须注意缓冲区大小、分组尺寸以及分组丢失率等问题。分组丢失的越多，接收端的语音质量就会越差；而另一方面，分组尺寸太大又会增大等待时间，并造成缓冲区的增大。

2.3 语音压缩编解码技术

用于VoIP中的常见的编码器有：ITU－T G.723语音编码器、ITU－T G.728语音编码器、ITU－T G.729语音编码器。语音编码器的主要功能就是把用户语音的PCM样值编码成少量的比特（帧）。语音编码器是建立和处理VoIP分组的发动机，它由DSP驱动。

G.729原来是8kb／s的话音编码标准［4］，现在的工作范围扩展至6.4～11.8kb／s，话音质量也在此范围内有一定的变化，但即使是6.4kb／s，话音质量也还不错，因而很适合在VoIP系统中使用。

3 系统软件开发架构

由于OMAP3530是ARM和DSP异构双核处理器，目前还没有一个统一的集成开发环境，所以本设计需要采用ARM端QNX IDE和DSP端CCS IDE两套集成开发环境。系统的软件架构如图6所示。

图6 系统软件架构

为了简化软件开发，DSP的软件结构从通用处理器（GPP）的编程环境中抽象出来。在OMAP软件体系结构中，这种抽象通过定义一个接口，使GPP成为系统的主控者来实现。该接口由一系列包括设备驱动接口的API组成，提供一种通信机制，使得GPP应用程序能够完成诸如初始化、控制DSP任务、与DSP交换信息、接收或发送数据流到DSP、状态查询等工作。通过资源管理器接口，GPP应用程序调用DSP的功能函数，就像在本地调用一样。这种软件体系结构允许开发人员在GPP的操作系统上使用C语言编程，而不直接面对底层硬件，并且使开发人员得以容易地使用符合标准的DSP算法，而无需深入了解DSP就可以利用DSP来加速信号处理任务，实现多媒体、语音或其他功能，从而充分发挥OMAP处理器的性能。

4 系统实现

4.1 语音采集和播放模块

语音采集和播放模块的作用是将音频模拟信号转换为数字信号，并对信号进行PCM编码。QNX操作系统中语音采集与播放是相似的，下面介绍具体步骤。

（1）打开PCM设备

打开一个播放设备：

（2）配置PCM设备

snd＿pcm＿plugin＿info（）使用插件转换器，如果硬件有一个自由子通道，插件转换器可以做任何转换；snd＿pcm＿channel＿info（）直接访问硬件，这个函数只返回硬件的处理能力。

（3）控制语音转换

实际的语音转换是由snd＿pcm＿voice＿conversion结构体控制的。

（4）准备PCM子通道

采集或播放语音流的下一步就是准备运行的已分配的子通道。

① 当没有用插件接口时使用snd＿pcm＿plugin＿prepare（）；

② 当没有准备好时，snd＿pcm＿channel＿prepare（）函数会依据指定的通道调用snd＿pcm＿capture＿prepare（）或snd＿pcm＿playback＿prepare（）。

③关闭PCM子通道，完成采集或播放语音数据时，可以通过调用snd＿pcm＿close（）关闭子通道。

一旦打开和配置了一个PCM回放设备，并且准备好了PCM子通道，就可以采集或播放语音数据了。

4.2 语音网络传输

VoIP中网络传输技术主要是RTP和UDP［6］。由于实时传输协议RTP提供具有实时特征的、端到端的数据传输业务，因此VoIP可用RTP来传送话音数据。在RTP报头中包含装载数据的标识符、序列号、时间戳及传送监视等，通常RTP协议数据单元是用UDP分组来承载，而且为了尽量减少时延，话音净荷通常都很短。IP、UDP和RTP报头都按最小长度计算。VoIP话音分组开销很大，采用RTP协议的VoIP格式，在这种方式中将多路话音插入话音数据段中，可以提高传输效率。

用较短的数据包来传送语音业务是很重要的。如果在网络中丢失了一个数据包，由于短包中包含重要语音信息的可能性较小，所以影响不大。大多数低速率语音编解码器都只产生短语音数据包，一般帧长为10～30ms，数据包的长度为10～30字节，一种典型的数据包是40字节，采用短包可以使数据比特穿过输入接口的等待时间缩短。