Voice over BLE case study: Using bluetooth LE remote controller inside oolegg's Voice search framework 原文

第一部分 引言

虽然越来越多的新电视或STB连接到互联网，但最终用户体验不是很好，因为屏幕上的键盘界面不切实际，需要用户通过以令人烦恼的缓慢的速度移动光标进行键入。可能的解决方案是使用语音识别来执行各种智能电视功能，包括语言命令（zapp频道，控制音量，打开各种应用），搜索互联网内容，甚至在社交网络服务上发布/分享评论。这个问题是公认的，市场上可以找到带有语音搜索功能的智能电视机遥控器。一个例子就是LG的“Magic Remote”遥控器品牌。然而，由于它们依赖于标准的BR/EDR蓝牙技术，现有解决方案为最终用户带来了新的问题：高功耗和这些RC的电池寿命不可接受。更好的选择将是蓝牙LE，以低功耗设计的技术为主要目标。

在第二节和第三节中，我们简要介绍了标准蓝牙和蓝牙LE技术，以便提供足够的背景信息来阐述BLE语音传输的挑战。在第四节制定问题陈述之后，在第五节中，我们提出了一个针对BLE语音用例的解决方案。最后，在最后两节，我们提出验证结果并得出结论。

第二部分 蓝牙和蓝牙概述

蓝牙是一种用于短距离数据交换的无线技术，使用2.4至2.485 GHz的无执照工业，科学和医疗（ISM）频段的无线电传输。由爱立信于1994年创立，蓝牙最初是开发商作为无线替代已知的RS-232数据线的。它允许我们在设备之间无线地共享语音，数据，音乐，照片，视频和其他信息。

蓝牙低功耗（蓝牙LE，BLE，作为Bluetooth Smart推广）是2011年蓝牙规范v4.0中引入的原始蓝牙品牌的扩展。BLE虽然被设想为扩展，实际上是从头开始设计的新技术，具有以下目标：

• 最低功率运行
• 最低可能的延迟

然而，由于设计限制，它必须重用尽可能多的蓝牙RF频谱和底层蓝牙软件栈。采用所提到的设计决定使得所谓的双模式蓝牙芯片的存在。这些芯片可以同时支持标准的v4.0蓝牙应用（BR/EDR设备）和新的LE应用（LE设备）。图1中示出了双模设备的蓝牙软件栈。

图1 双模蓝牙解决方案

第三部分 BLE架构

BLE不太明显但又重要的特征之一是它被设计为作为可扩展框架来交换数据。与传统蓝牙相比，这是一个根本的区别，它专注于一组严格的用例。另一方面，BLE被设想为允许任何拥有想法和一堆数据的人都可以实现它，而不必太深入底层技术。这里重要的是要提到BLE不是为了支持高数据速率而设计的，而是专注于最低功耗传递小而不频繁的数据位的。空中数据速率为1 Mbps，但应用吞吐量取决于连接参数。通常为0.2 Mbps。BLE技术的全面覆盖可以在[1]中找到。然而，在本文中，我们只定义了关键的BLE术语和概念，以形成问题陈述，并阐述了一个提出的解决方案。

通用访问配置文件（Generic Access Profile，GAP）是确定两个设备如何（或不能）彼此交互的基石。它提供了任何BLE实现必须遵循的框架，以允许设备发现彼此，广播数据和建立连接。连接只是在预定义时间之间的设备之间的一系列数据交换。每个交换都称为连接事件。以下三个连接参数是在建立连接期间由设备传达的关键变量：连接间隔（connection interval，两个连续连接事件之间的时间），该值范围从7.5 ms到4 s）；从设备延迟（slave latency，从设备可以选择跳过而不会有断开连接的连接事件数）和连接监视超时（connection supervision timeout，考虑连接丢失之前两个接收到的有效数据包之间的最大时间）。

通用属性配置文件（Generic Attribute Profile，GATT）详细介绍了如何通过BLE连接交换数据。与GAP相反，它仅涉及实际的数据传输过程和格式。GATT还为所有基于GATT的配置文件提供了参考框架，涵盖了精确的用例，并确保了来自不同供应商的设备之间的互操作性。GATT了解的一个重要概念是服务器/客户端关系。所有事务由主设备即GATT客户端启动，GATT客户端接收从设备，即GATT服务器的响应。BAT中的GATT事务基于称为“配置文件”，“服务”和“特征”的高级嵌套对象，如下图所示：

图2 GATT配置文件，服务与特征之间的关系

特征是GATT事务中的最低层次的概念，封装了单个数据点（尽管它可能包含相关数据的数组，例如来自3轴加速度计的XN/Z值等）。服务用于将数据分解为逻辑实体，并包含称为特征的特定数据块。服务可以具有一个或多个特征，并且每个服务通过称为UUID的唯一数字ID将其自身与其他服务区分开来。配置文件是由Bluetooth SIG或外围设备设计人员编译的预定义的服务集合。例如，通过GATT配置文件（HOGP）的人机接口设备（HID）组合了HID服务，电池服务和设备信息服务。HID设备是人类用于控制计算机系统的操作的一种计算机设备。除了最典型的例子，如：摩丝，键盘，轨迹球和操纵杆，BLE遥控器也属于HID组。正式通过的关于GATT的简介的完整列表可以在[2]中找到。

第四部分 问题声明

根据上一节提供的信息，我们可以确定BLE语音两个问题：

• 现在BLE没有指定传输低带宽语音音频数据的默认方法。
• 按照设计，BLE不支持高数据速率。对于通过BLE实现的任何自定义语音，我们必须了解应用程序吞吐量的限制。

第五部分 语音实现

自4.3版（API 18级）以来，Android已经引入了对BLE的内置支持，现在提供了应用程序可以用来发现设备，查询服务和读/写特性的APls。尽管在Android BLE API之上开发用于低带宽语音音频数据传输的定制服务是可能的，但它带来了可移植性问题。对于BLE的整体Android API支持仍然是一个移动目标，APls有望改变。因此，在本文中，我们提出了一种不同的，更通用的方法。这个想法是利用现有的HOGP配置文件，用于关键事件和语音流。HOGP设备上按键事件的数据流如下图所示：

图3 HOGP设备按键事件传播在Android平台上

重要的是强调蓝色HOGP组件对关键事件类型和键事件数据有效负载是不可知的事实。所有事件都写入内核HID子系统。内核HID子系统识别常规的按键事件，并将其进一步传播到内核输入框架。但是，HID不知道的关键事件不会被丢弃。事实上，所有的事件都在内部排队，并可以通过HID原始界面从用户空间访问。

这些事实为我们提供了足够的动机，将语音流视为新的特殊类型的一系列离散的HOGP键事件。这种方法的关键优点是我们不必为低带宽语音数据实现新的BLE配置文件，也不需要扩展现有的HOGP BLE配置文件。HOGP配置文件可以“按原样”使用，作为语音有效载荷的虚拟代理，被视为一种新型的键事件。在这方面，我们可以提出BLE语音搜索实现，如下图所示：

图4 提出的语音流数据流

这个概念的实现只需要有两个相对简单的软件组件，而没有其他Android系统的修改。第一个组件（btvoiced）是一个自定义语音搜索守护程序，它从HID原始设备读取pcm样本，并将它们写入第二个自定义组件，即捕获设备ALSA驱动程序（snd_bt）。

语音流调制（Voice Stream Modulation，ADPCM）

ALSA捕获设备是用于读取语音输入流的pcm样本的Andorid语音搜索框架的标准接口。ALSA设备的捕获格式由框架暗示：16位采样@ 16000Hz，1个通道。很明显，这种格式需要256Kbps的吞吐量，这比BLE（200Kbps）的典型应用吞吐量高。这就是为了减少所需的吞吐量，将pcm样本的ADPCM调制引入RC侧的原因。

自适应差分脉码调制（Adaptive Differential Pulse Code Modulation，ADPCM）是一种广泛应用于整个电信行业的音频编码技术。它通过计算标准脉码调制（PCM）中两个连续样本之间的差异并将“预测”下一个样本增量（从前一个采样增量）的误差编码为真实样本增量来工作。它是一种有损压缩技术，它可以实现4：1的压缩比，同时返回高质量的信号，具有快速调制/解调所需的很少的处理能力。ADPCM算法的内部结构不在本文的范围之内。如果有兴趣，读者可以在[3]中了解更多。

语音搜索守护进程（BTVOICED）

守护程序从hidraw设备读取音频数据并将其写入ALSA捕获设备。详细信息如下：

1. 初始化时，它将通过上述/dev/snd_bt接口通过自定义ioctl调用创建一个音频捕获设备。初始化后，在系统中创建标准的ALSA音频捕获设备：/dev /snd/pcmC0D0c。

2. 它从hidraw设备读取数据。这个读取是一个阻塞操作，只有当有新数据可用时，read()调用才会返回。

我们有四种类型的数据包：

1. RC键
2. 启动音频控制包（在RC上按下麦克风键时发送）
3. 停止音频控制包（当RC上释放麦克风键时发送）
4. 音频数据包（语音有效载荷）

接收到的数据包的处理比较简单。RC键只是被忽略，因为内核输入事件框架将会处理它们。在启动音频控制包时，只需要重新初始化ADPCM解码算法，以避免解码的pcm流中的DC偏移伪像（artifacts）。语音有效载荷数据包被ADPCM解码，缓冲用于最小化用户空间 - 内核空间写入遍历并写入/dev/snd_bt。由于Android语音搜索应用程序是决定何时停止捕获的组件，基于静默期检测（silence period detection），我们需要覆盖用户太早释放麦克风键的情况，也就是在应用程序检测到静音期之前。因此，停止音频控制分组时，btvoiced继续以静音字节（silence bytes）馈送alsa捕获设备，直到Android应用程序决定停止捕获。这通过将零写入/dev/snd_bt来实现，直到write()调用开始失败。

btvoiced守护进程的作用可以归纳为：从hidraw设备中提取音频数据，ADPCM解码，将PCM写入/dev/snd_bt以及停止音频控制数据包的静音填充。

捕获设备Alsa驱动程序（snd_bt）

snd_bt是一个内核模块，提供：

1. 一个简单的可写的char设备/dev/snd_bt作为btvoiced守护进程写入解码的pcm样本的接口。

2. 标准接口，Android语音搜索框架读取pcm采样，以ALSA捕获设备（/dev/sndipcmCxDxc）的形式，

创建一个可写的char设备是简单的注册新的struct miscdevice以及所需的文件操作：open()，write()，ioctl()和close()。ioctl()操作用于创建ALSA设备，如下所述，write()操作是捕获过程的主要部分。

为了创建捕获设备接口，snd_bt驱动程序使用内核ALSA结构和API函数。

模块中使用的核心内核ALSA结构如下：

• struct snd_card

ALSA表示声卡。

• struct snd_pcm

可实现捕获，播放或控制设备的PCM实例的ALSA表示。

代表btvoaved守护进程的Idev / snd bt上的核心内核ALSA API函数称为ioctl（）：

• snd_card_create()

创建和初始化声卡结构。

• snd_pcm_new()

创建一个新的PCM实例，它是捕获设备的ALSA表示形式。

• snd_pcm_set_ops()

将PCM操作函数注册到PCM实例。PCM操作函数prepare()，trigger()和pointer()是捕获过程中由ALSA内核调用的回调函数。

• snd_card_register()

注册分配给声卡的所有设备。在我们的例子中，我们只有一个捕获设备。在此调用完成后，ALSA捕获设备已准备好由Android语音捕获框架使用。

联合起来

总体RC数据包处理如下图所示

图5 RC数据包处理

在处理RC数据包时，可以区分两种不同的STB操作模式。标示为“HOGP设备按键事件处理”的第一种模式是图3中更详细说明的键事件的常规处理。图4所示的第二种模式“语音流处理”是BLE实现中的实际语音。通过按下并释放RC上的“魔术”麦克风键，可以启动这两种模式之间的切换。

第六部分 验证

作为验证工具，我们采用了两步法。首先我们验证了所捕获的语音流的质量。之后，我们验证了与语音搜索应用程序的正确集成。

对于第一步，我们以PCM转储的形式录制语音搜索模式，语音搜索框架从snd_bt Alsa设备读取（见图4）。使用Audacity（开源音频编辑器和录像机），我们验证了没有明显的损坏，如DC偏移，PCM样本丢失等。下图是在Audacity中导入的口语搜索模式PCM转储的示例。

图6 “打开Netflix”测试模式pcm转储导入audacity

作为第二步，我们通过BLE RC功能测试了Google语音搜索的整体用户体验。一组20名测试对象通过以下方式传达了一系列预定义的搜索模式（如可口可乐，梅赛德斯，著名电影演员等）

• BLE遥控器
• 标准USB麦克风

并验证了搜索结果。在这两种情况下，我们的识别率达到了80％。尽管有前途，这些结果是有争议的，因为它们高度依赖于Google的语音识别算法。对于更正式的验证措施，我们建议改进步骤1的方法。如何正式证明BLE传输造成的语音流中没有任何破损的问题仍然存在。

第七部分 结论

在本文中，我们提出了一个在Android平台上使用BLE遥控器作为语音捕获设备的解决方案。我们决定使用现有的HOGP配置文件，将语音流视为一系列常规的键事件，而不是为低带宽语音开发自定义的GATT服务。提出的概念通过两个软件模块实现：语音搜索守护程序（btvoiced）和ALSA捕获设备驱动程序（snd_bt）。通过引入语音流的ADPCM调制来解决由BLE的低数据吞吐量施加的限制。然而，正式的测试和验证程序没有定义，作为非正式措施，提出的解决方案的最终用户体验是有前途的，达到80％的识别率。正式的验证工具和测试程序的定义是今后工作的主题。

致谢

这项工作得到塞尔维亚共和国教育，科学和技术发展部的部分支持，得到拨款：32014。

参考文献

• 1. Kevin Townsend, Carles Cufi Akiba and Robert Davidson
     Getting Started with Bluetooth Low Energy, O'Reilly Media, Inc 2014
• 2. [online] Available: https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx#GATT
• 3. [online] Available:
     http://shatura.laser.ru/Articles/Dsp/ApplicationsHandbook/chapter_12.pdf