英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料
摘要
本文主要介绍了一种通过蓝牙和wifi来实现短距离无线网络语音通信的安卓移动应用。该应用可以尽可能的取代无线设备的一两种功能。该应用程序被设计来从多个设备同步接收音频流并且再送出它们。本文以下部分会解释这个应用程序主要设计思想，比如音频录制与播放、音频编码与数据传输。
关键词：无线网络，安卓，数据传输，音频编码
1.介绍
服务于移动设备的分散式应用程序平台，如APP Store或Android Market都不断地促进着越来越多的应用程序的出现，极大的改变了市场的格局。虽然苹果公司率先推出这一变化，然而由于Android Market极大的方便了设备制造商和应用程序开发者，使得Android Market成为了最受欢迎的分散式应用程序平台之一。由于快速增长的全球安卓终端数量，应用开发者们为了寻求大量的潜在用户瞄准了这个平台。这里有许多不同种类的应用程序如游戏、娱乐或访问社交网络。用户甚至可以找到应用程序取代手机本地通信的应用，如音频或视频通信应用程序。这用应用程序成功的背后突出了这样一个事实：尽管电话可以让用户们通过文字或者语音互相联系，但是还是有很多种情况不适合用这种手机自带的原生通信方式。关于语音通信，有传统上由其他种类的移动电话不同的设备的处理不同的使用情况。双向无线电收发信机允许对等体建立，而无需额外的基础设施上的语音通信，只要该设备是在范围内。这在不同的场景非常方便，尤其是在没有蜂窝网络或当用户无法承受维持一个无限的通话存活时间。由于wifi和蓝牙，智能手机间有很强的连通性，但是它们不提供允许用户去让它们作为一个双向无线电使用的科技。这就是应用程序的目标——Android内部通话系统：转变Android终端作为一个双向无线电，同时让Android终端的连通性尽可能的最好的发挥出来。本文剩下的部分以如下所示来构建：接下来的部分解释开发应用程序的主要设计思想，在不同的无线网络中放入特殊的放大器。第三部分解释了Android内部通讯应用程序的主要特点。最后我们会做出一些结论。
2.设计思想
本节介绍了在应用程序开发过程中考虑到的不同的设计思想。具体而言，下一节给出了系统的总体架构，在该系统中，应用程序的主要模块有：音频记录和播放模块，音频编码和数据传输模块。这些模块会在以下部分解释。
2.1 结构
图1显示了一种通用的音频传输应用架构。它显示了一个典型的音频流链。首先，音频被数字化和记录。之后，记录的数据的取样频率通常在20或30毫秒。这些样本会进行编码以减少传输的比特率以及最后我们会发送这些音频样品。在开发的应用中，数据通过无线网络传输，主要是通过蓝牙和Wi-Fi。当音频样本到达收听设备时，该样本将通过音频解码器，该解码器会将数据解码，并将其发送给音频播放模块，之后音频播放器模块就会复制出该音频。
图1 系统架构
这里所提出的应用是双向的，即不同的设备可以作为发射器和接收器工作。该图显示了从一个设备到另一个的典型传输。此外，图1也反映了在应用程序开发中应考虑的要点。首先，音频录制和播放模块要分别允许捕获和播放音频。音频需要进行编码，然后通过相应的块解码，最后音频必须再通过一个通道传输。如下给出每个模块的更多的分析。
2.2 语音播放和录制
在语音录制和播放模块的发展过程中，必须被考虑到的是在Android中应用程序的主要部分是在安卓虚拟机（JVM）上运行的。这个特点使应用程序对垃圾收集器的暂停十分敏感，并且这也是为什么所有的Android多媒体应用程序编程接口（API）实际上都依赖于原生代码[1]。对于音频，有两个Java水平的API可以用：一个是高等级的API，其代表是MediaPlayer 和MediaRecorder类。这种API已经被构建成可以编码、解码与流通音频内容的形式[2]。然而，这种API不提供方法在实时问题中来访问流，这让它无法发展一些需要实时语音进程的应用。
再者，作为低等级API的代表的 AudioTrack 和AudioRecord 类。这些类是java包装的“libmedia”内置的原生API。此外，两个附加的多媒体API已被添加在较新的Android版本。他们是原生API并基于流行的跨平台的多媒体体系。这些API有：OpenSL EStrade;1.0.1.出现于等级9的Android API；OpenMAX ALtrade;1.0.1. 出现于等级14的Android API。这些原生API被设计为服务于最常运行本地代码的应用程序。这些库出现之前，应用程序，如游戏，通常运行本地代码，如Open GL，都不得不用Java代码来代替控制音频，这就造成了不必要的开销。以上所有提到的音频API都基于声音驱动系统运行。实际上，是没有标准的声音系统的。只有最新的Android版本（Ice Cream Sandwich）建立了ALSA（高级Linux声音架构）作为系统默认的声音。从一开始就缺乏良好的声音系统已经导致了声音应用的碎片化，它们大多数在声音延迟的问题上都表现得很差[3]。Android开发人员在去年谷歌I / O 中解释[4]，大部分延迟都会被驱动和芯片组所解决。因此，解决问题的办法很可能会以一个由制造商引导的移植的形式到来，而不是一个软件补丁的形式。本文介绍的应用程序使用Java低等级的音频API，因为原生API没有那么明显的延迟。在这一点上，该API允许记录和播放未编码的音频波形，如脉码调制（PCM）格式。对于这个我们所研究的应用程序中，其音频录制的特点有：8kHz的采样频率，每个采样16比特大小和单个信道。此外，为了达成能尽可能的实现用户所以要求的目标，研究者们开发了三种方法，用于激活音频记录和发送：静态，手动和自动。第一个是发送任何一个比所选定的阈值更高的音频幅度阈值的声音。此阈值可让用户在任何时间通过拖动标记来改变。第二个是一种推动来说话的机制（PTT），这种机制使用音量或者耳机按钮来激活录制和发送。最后一种方法通过分析音频范例，如背景噪声和瞬时振幅来检测人声。应用任何这三种方法之一，应用程序都能够减少噪声和带宽使用率。由于应用程序会在各种不同的情况下使用，每个方法是否适合都应取决于特定环境。
2.3 语音录制
编码一个媒体流的主要目的是为了减少传输数据的总量，使大部分媒体具有固有特性（如：两个连续样本之间的关联度）。另一方面，用于本地通信提供的带宽速率，足以传送未压缩的音频流的几种无线技术。在这种情况下，电源消耗的问题就出现了：在数据压缩中需要折衷，那么就可以极大的减少带宽需求，并且也可以处理编码和解码时的消耗。此外，另一个需要考虑到的问题是无线通信的使用和覆盖范围。蓝牙和Wi-Fi会基于信号噪声比来动态改变其传输速率，这就意味着其传输速率是其覆盖区域的边界中最低的。有很多在安卓平台上成功编译和使用的代码。由于java和JVM的特点，它们能比C和C 代码更有效的运用JNI（Java原生接口）。在这个项目中，我们使用了Speex [ 5 ]，它是一个广泛使用的服务于语音应用的开源音频编码。Speex可以产生恒定或可变比特率，但改变模式需要浮点运算的使用，而这在移动设备处理器中不常有。表1显示了可用的Speex编码器模式。在每个模式中还给出了最终音频的质量的描述及计算花费。由于希望能在覆盖边界上有更好的表现以及在编码和解码时附加更低的延迟，我们正在用的这个应用程序的音频编码通常小于5ms。当使用Speex代码时，我们必须选定一个模式来确定其质量水平。就如表1所示，Speex模式5提供了一个优秀的音频质量、压缩率和算法复杂度。
表1 Speex模式特点
|
模式 |
品质 |
比特率（bps） |
每秒百万（次）浮点运算 |
品质/描述 |
|
0 |
- |
250 |
0 |
不发送（DTX） |
|
1 |
0 |
2150 |
6 |
声码器（大多为缓和噪声） |
|
2 |
2 |
5950 |
9 |
十分明显的噪声，可理解性强 |
|
3 |
3-4 |
8000 |
10 |
噪声有时可察觉 |
|
4 |
5-6 |
11000 |
14 |
通常只有用耳机才可察觉噪声 |
|
5 |
7-8 |
15000 |
11 |
需要好的耳机才能区分不同 |
|
6 |
9 |
18200 |
17.5 |
用好的耳机也很难区分不同 |
|
7 |
10 |
24600 |
14.5 |
完全清晰的声音，质量优秀的音乐 |
|
8 |
1 |
3950 |
10.5 |
十分明显的噪声，可理解性强 |
2.4 数据传输
如上所述，该应用程序使用蓝牙和Wi-Fi作为无线网络进行数据传输。这两个网络每一个都有其自身的特点和实施细节，这会在后面的章节中讨论。而不论是在哪种环境中。我们都需要定义一个协议去传输编码后的音频和控制管理信息。为了达成这一目的我们会使用协议缓存器[6]。这个是一种从一个协议定义的语言来生成java或C 代码的编译器。如下是一个在协议缓冲区语言中定义的音频数据包的例子。
message AudioMessage { message AudioSample { required int32 seq_number = 1; required bytes audio = 2; } required int32 user_id = 1; repeated AudioSample audio_sample = 2; }
这段代码是用来序列化、解析和形成二进制流。它定义了一个32位识别（user_id）的包和一个未定义的音频样本（audio_sample），而这又是由一个序列号（seq_number）和音频字节（audio）组成的。通过使用协议缓冲区，让我们能完美、优化和可扩展地定义一个完整的协议。
2.4.1 蓝牙
在Android设备上，应用蓝牙[7]实现双向无线电应用程序面临着很多挑战。 首先，Android设备需要可被发现来进行设备的配对，因此这需要拥有这台设备的使用者知道如何设置为可被发现模式。在Android的4.0版本之前都是必要的，在这些设备中有一个选项可以把设备设置为一直可发现模式。那么现在，我们假设所有的设备都想通过蓝牙通信并且已经是可发现和可配对的了。如果目标设备不可配对，这可能是需要通过系统蓝牙设置中分别设置每个应用程序来让它们配对。这些情况都需要在用户交互接口的设计中被考虑到，所以建立一个连接的进程都会尽可能的简单。
配对在建立安全连接中必要的。安全连接是Android版本2.3.3中一个独特的设计。自从那个版本以后，我们可以建立向未配对设备进行非安全连接，但是这些设备仍然需要可被发现并且如之前提到的，要设置为一直可发现，这些在Android 4.0之后才开始出现。为了保持与主流设备数量上的通用性，在应用程序中只能使用安全连接。
一旦设备被配对了，那么在公共API中，只有可用的蓝牙配置文件才是蓝牙串行端口配置（SPP）。蓝牙SPP提供了一个RFCOMM（串行电缆仿真协议）。RFCOMM提供了可靠地传输、数据监测和数据流控制，这些都是不适合时间相关数据的。值得注意的是，它应该可以接触到高级音频分布用户配置文件（A2DP）。A2DP基于通用音频/视频分布配置文件（GAVDP）并且允许高质量实时音频流的分流。
为了在实时音频通信中有好的表现，一个在传输和接收中使用的队列系统被发明了出来，它可以尽可能的避免实时RFCOMM的缺点。
图2表示了4种会使用的队列。蓝牙输出队列（BOQ）和蓝牙输入队列（BIQ）是不能被应用层控制的系统队列。这些队列被设计来避免RFCOMM协议的不可预知的影响。
图2 蓝牙通信队列
至于其他2个队列，在最好的传输环境下，蓝牙连接提供过多的带宽。在这种环境下，应用输出队列（AOQ）和应用输入队列（AIQ）仅仅作为一个音频录制和播放抖动减少/避免缓冲来运作。
当蓝牙连接变弱，因为音频编码比特率高于连接容量，BIQ会清空并且BOQ会充满。在这种情况下，添加到BOQ的样本无法被删除并且如果蓝牙栈不去除一个超时例外的话，该样本将会被发送。因此，AOQ会被填满并且将会在先进先出（FIFD）管理器中出栈该样本。综上所述，编码音频可以帮助避免这种情况，因为这样需求的带宽更窄。lt;
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[152010]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
