基于高速公路网的无线语音系统的设计

康维新，缪 晶

(哈尔滨工程大学 信息与通信工程学院，哈尔滨 150001)

目前，随着中国车辆保有量的增多，高速公路里程不断延伸.有限的维护力量与增长的公路里程的矛盾，成为了一个越来越突出的问题[1].目前前后方维修工作的信息沟通主要依赖移动电话方式，成本较高，而高速公路网的现有网络资源得不到充分利用.

鉴于以上问题，本文提出了基于高速公路网的无线语音系统的设计，系统硬件平台采用三星公司S3PV210作为主控单元，搭载Marvell-88w8686无线wifi硬件模块，软件平台采用开源的，可移植性强的嵌入式Linux系统，结合了数字化音频采集，G726音频编解码，RTP/RTCP流媒体协议与多线程技术，采用GTK+技术作为人机界面[2].整个系统模块化设计，具有成本低廉，体积小，扩展性好，移动性强等特点，系统测试表明，语音辨识度高，实时性好，能够满足交通管理人员的要求.

1 系统总体方案及架构

1.1 系统硬件设计

本系统分为服务端与客户端2个部分，其中服务端作为一个可移动终端，在高速公路上使用，用于接收与发送语音信息，服务端采用基于Cortex-A8架构的S3PV210作为硬件核心处理器，系统架构如图1所示.

图1 系统架构图

服务端的硬件构成主要有：S3CPV210 ARM处理器、WM8960声卡、SD-WIFI模块、FALSH、SDRAM.WM8960作为采集播放核心，该芯片内置有麦克风接口和立体声耳机驱动器以及立体声24比特sigma-delta模数转换器(ADC)和数模转换器(DAC)，用于采集播放原始PCM音频；SD-WIFI模块以Marvell-88w8686为无线处理核心，用于服务端无线接入高速公路网络；服务端配备4.3寸LCD触摸屏，实现人机交互；FLASH用于存储系统及用户程序；SDRAM为服务端提供工作内存服务.

客户端为PC端，满足客户端软件安装配置即可.

1.2 系统软件设计

在服务端，本文选用嵌入式Linux系统，按功能将软件程序分为四层:引导加载程序，系统内核程序，文件系统程序，应用程序如图2所示.

图2 软件结构框图

引导加载程序主要用于开机引导嵌入式Linux系统的启动、配置正确系统环境，本系统选用对处理器架构通用性好的u-boot；嵌入式系统内核选用Linux3.0.1版本内核，文件系统选用能够更好的支持大容量NAND FLASH的yaffs2文件系统，系统程序存储在FLASH中，在SDRAM中运行；应用程序工作在系统程序之上，音频的采集播放、编解码，wifi的连接均工作在这一层，采用ALSA数字音频编解码技术播放、采集PCM音频数据，G.726编解码PCM数据，RTP/RTCP实现编码音频数据的发送、接受.

在客户端，采用Gtk+图形界面技术实现人机的交互，实现与服务端的连接与音频的设置.系统软件设计框图如图3、4所示.

图3 服务端软件设计

图4 客户端软件设计

2 关键技术实现

2.1 ALSA音频采集的实现

ALSA(Advanced Linux Sound Architecture)，高级Linux声音架构的简称,它在Linux操作系统上提供了音频和MIDI(Musical Instrument Digital Interface，音乐设备数字化接口)的支持[3].在2.6系列内核中，ALSA已经替换OSS(Open Sound System，开放声音系统)成为默认的声音处理模块.

ALSA首先打开采集或播放设备，为设备参数申请空间，然后设置采集播放参数，本文采集播放采样率8 kHz，量化位数16，单声道的PCM语音数据，最后关闭设备.音频采集流程如图5所示.

图5 ALSA采集流程图

2.2 G.726编解码的实现

声音是一种模拟信号，为了计算机可以识别处理声音，需要进行模数转换，并且进行PCM编码，即脉冲调制.G.711是现在使用最普遍的编码技术，它是目前全世界电路交换电话网中使用的编码技术.G.711使用A率或μ率PCM方法对采样率为8 kHz的音频数据进行编码，压缩后的音频码率为64 kbit/s.在保证声音质量的基础上，为了进一步利用占用线路资源，还需要对语音数据进行进一步压缩，进一步压缩编码的方法就是采用ADPCM，而G.726编解码器就是采用了ADPCM算法的编解码器[4-5].

ADPCM综合APCM的自适应特性和DPCM系统的差分特性，是一种效果比较突出的波形编码算法.它的关键思想是：1)利用自适应的想法改变量化阶的大小，即使用大的量化阶去编码比较大的差值，使用小的量化阶去编码比较小的差值.2)使用上一个的样本值预测下一个输入样本的值，尽量减小实际样本值和预测值之间的误差值.它的编码框图见图6.

图6 ADPCM编码框图

通常需要将信号从时间域转换到频域进行处理，式(1)、(2)所示:

k=0,1,…N-1

(1)

k=0,1,…N-1

(2)

PCM与ADPCM在算法上都没有时延，因此可以应用在语音的实时编解码.将语音比特流转换为24 kbit/s的数据流，降低了对网络带宽的要求，适宜网络传输.

2.3 RTP/RTCP传输的实现

RTP被定义为在点对点或群播的传输情况下工作，建立RTP的目的是提供时间信息和实现流同步.RTP的通常使用建立在UDP(User Datagram Protocol，用户数据包协议)上，但也可以在TCP(Transfer Control Protocol，传输控制协议)或ATM(Asynchronous Transfer Mode，异步传输模式)等其他协议之上工作.RTP只有依靠RTCP才能保证实时数据的传输，也就是说，RTCP为RTP提供按顺序传送数据包的可靠机制，还有流量控制[6-7].

实时传输控制协议RTCP在RTP会话期间，各参与者按时地发送RTCP包，RTCP包中含有发包数、丢包数等信息，所以，服务器可以利用这些信息随时调节传输速率的大小，甚至调节有效载荷类型.RTP和RTCP互相配合使用，能以有效的控制和最小的代价使传输效果最大化，所以，特别适合用于音视频等实时流的传输.下面分别介绍RTP与RTCP发送数据报的基本格式.

2.3.1 RTP报文格式

见图7.

图7 RTP报文格式

版本(V)：2 bit，RTP的版本.此协议定义的版本为2.

填充(V)：1 bit，若设置了这一位，则意味着此包在尾部需要填充多个数据位.填充的目的主要用于扩展自定义的算法，或者用于在底层的数据接收发送单元中传输多个RTP包.

扩展(X)：1 bit，若设置了这一位，表示在固定头后面会扩展出一个数据头.

CSRC计数(CC)：4 bit，CSRC计数包含了紧接在固定头后面CSRC识别符的个数.

标志(M)：1 bit，视具体协议的解释而定.它主要用来标记数据流中重要的情况，如帧边界.

负载类型(PT)：7 bit，设置了携带数据的格式，视应用情况而定.携带数据的类型数字和携带数据的类型可以建立一种映射.其他的携带数据类型数字可通过非RTP的方法动态定义.

序列号(sequence number)：16 bit，序列号的初始值是随机的.每发送一个RTP数据包，序列号的值加1，接收端根据序列号的值来确定失去的包并重新建立包的序列.

时间戳(timestamp)：32 bit，时间戳反映的是RTP数据包中第一个数据被采出来的时间，时钟频率依赖于携带数据格式的类型.

SSRC：32 bit，SSRC段标识同步源.此标识是选定的，以使同一RTP包连接中没有两个相同的SSRC标识的同步源.即使几乎多个源不可能选择同一个标识，但所有RTP实现都必须防止错误.

CSRC列表：0到15项，每项32 bit.CSRC列表表示包内的对载荷起作用的源.标识数量由CC段给出.如超出15个作用源，也仅标识15个.CSRC标识由混合器插入列表中，采用作用源的SSRC标识.

2.3.2 RTCP包类型

SR(SenderReport)：发送者报告，当前活动发送者发送、接收统计.

RR(ReceiverReport)：接收者报告，非活动发送者接收统计.

SDES(SourceDescription)：源描述项，包括CNAME，NAME等，CNAME项的SDES包必须包含在每个组合RTCP包中[8].

BYE：表示结束.BYE作为最后一个包发送.

APP(application)：应用特定函数.

本文移植了JRTPLIB库，通过库函数的封装实现了RTP/RTCP的工作，在设置完G.726的配置参数后，会自动间隔发送RTCP流媒体协议控制包，如图8所示.

图8 RTP/RTCP发送/接收流程图

3 系统测试结果

在实验室中模拟搭高速公路网络环境，搭建了测试系统，如图9所示，无线wifi名称“Dlink-150”，路由速度100Mb/s.音频质量，算法复杂度，编解码时延是衡量语音指标的重要几个方面.语音基本参数如下表1所示.

表1 语音采集播放参数

从测试结果看，语音可懂度好，音频质量良好；算法复杂度中等，在时延方面，自身采集100 ms数据，单向编解码时延和通信延迟约300 ms，每一个采样点将编码为3 bit数据，传输带宽约为24 kb/s.

图9 系统测试

4 结 语

本文提出了基于S3CPV210 arm硬件平台和嵌入式Linux软件平台,用于高速公路信息网的无线语音系统解决方案,应用多线程机制解决音频同时播放、采集的问题；应用G.726编解码标准压缩音频流，降低音频冗余与带宽占用；应用RTP/RTCP实时传输与传输控制协议，更利于音频实时流在网络中的传输，减少网络时延，提高网络传输效率；在arm服务端应用wifi模块，使具备移动性；移动端体积小巧，功率消耗小，在客户端与服务端通过缓冲机制降低了语音时延.实验表明，在理想网络状况，采样率8 kHz，量化为数16，单声道的情况下，时延小于0.5 s，码率24 kbit/s，语音清晰，可懂度好.整个系统工作稳定，价格适中，操作简便，可以应用在高速公路养护保养的通信中.

参考文献：

[1] 刘立才, 康维新,张 强, 等. 基于高速公路信息网的移动嵌入式监控系统设计[J]. 应用科技, 2013, 40(3): 58-62.

[2] 宋国伟. GTK+ 2.0编程范例[M].北京: 清华大学出版社, 2002. 1-7.

[3] 罗苑棠. 嵌入式 Linux 驱动程序和系统开发实例精讲[M]. 北京: 电子工业出版社, 2009. 234-243.

[4] 廖广锐, 刘 萍. 基于ADPCM的语音压缩算法研究[J]. 计算机与数字工程, 2007, 35(7): 39-41.

[5] BENVENUTO N, BERTOCCI G, DAUMER W R,etal. Report: the 32-kb/s ADPCM coding standard [J]. Bell Labs Technical Journal, 1986, 65(5): 12-22..

[6] 赵 进, 叶 梧, 冯穗力. 基于RTP/RTCP的流媒体服务器技术研究[J].中国有线电视, 2004, 1: 6-9.

[7] SEGUI F B, CEBOLLADA J C G, MAURI J L. An RTP/RTCP based approach for multimedia group and inter-stream synchronization [J]. Multimedia Tools and Applications, 2008, 40(2): 285-319.

[8] OTT J, WENGER S, SATO N,etal. Extended RTP profile for real-time transport control protocol (RTCP)-based feedback (RTP/AVPF) [J]. Request for Comments, 2006, 4585.