汽车音响语音合成器设计分析

开篇：润墨网以专业的文秘视角，为您筛选了一篇汽车音响语音合成器设计分析范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：汽车音响语音合成器设计框架是一个系统化工程。在这个实现中，我们要将我们对于各种协议和设计的理解逐渐的模型化、层次化、清晰化。而对于模型、框架设计的讨论也能够加深我们对于协议中诸多细节的理解。首先，从协议的抽象概念设计来入手。通过解释了协议间的关系，现在我们要在设计中来体现出这种关系，还要来解释说明他们的应用关系模型。

关键词：汽车音响；语言；合成器

中图分类号：TN912 文献标识码：A 文章编号：1007-9599 （2012） 15-0000-02

1 引言

应用程序通过ECMA-323和汽车音响语音服务器沟通，而服务器内部的构架和设计都是基于ECMA-269和ECMA-TR88来实现的。能够使得我们更加清晰的理解ECMA各个协议间的关系。 接下来，分析整个项目的框架设计模型。用户的服务请求分为了两个阶段，一是用户认证和服务请求阶段，一是汽车音响语音交互阶段。在第一阶段，服务器会完成两个方面的工作，一个是对于用户的信息进行认证，检查用户的合法性和用户级别；一个是为合法用户的请求分配一个汽车音响语音服务器，来处理用户的汽车音响语音交互。

2 嵌入式汽车音响语言模型分析

用户向嵌入式服务器提出请求，请求来进行汽车音响语音的交互。它会将自己的用户信息加密后发给服务器，服务器会将解密后的用户信息和保存在用户数据库中的信息进行认证比对。

用户收到返回的信息以后，从中得到服务器的信息，并向这台服务器发出汽车音响语音服务请求，汽车音响语音服务器比对从嵌入式服务器发来的用户信息以后，就可以为用户提供相应的服务了。它会解析发来的服务请求，为用户提供对应的服务。服务结束以后，汽车音响语音服务器会将用户的服务记录发回给嵌入式服务器，并记录在相关的用户数据库中。

利用这样的设计，主要解决了一下几个方面的内容：

1.1 提供了用户认证的功能

提供用户认证的功能后，主要的方面式在安全性上得到了加强，保护了服务器的稳定性和安全性，另外就是就可以保存用户的相关信息，划分用户的服务类型，针对不同的用户的类型进行与之对应的服务种类，来提高服务的种类。

同时，通过对于用户服务的记录分析，也能够看出服务中的一些问题和分析服务的趋势，以供服务商来分析考虑。提高了项目的可用性和服务的可发展性。

1.2 嵌入式的处理机制

通过对于用户的类型和地域信息的分类，在不同的区域和负载等信息的综合权衡中选择分类来处理用户的请求，这样加快了服务的速度，提高了服务的质量。

1.3 解决了汽车音响语音服务在小型设备上的局限性

通过采用Client/Server的构架方式，将汽车音响语音识别与合成运算和处理的工作转到了服务器端。这样，就将能够将汽车音响语音技术应用到更多的低资源设备中。

通过这样的设计，大大加强了汽车音响语音服务的可应用性，也扩展了汽车音响语音服务在多个平台间的应用。下面的几个小节中，我们将分别的展开分析每个层次的设计细节和结构，让我们更加的清楚的理解整个的框架结构。

3 嵌入式架构模型

承接上一节的分析，这一节中我将着重从嵌入式服务器的构架模型和工作机理来展开详细的论述。

3.1 嵌入式语言服务器架构设计

嵌入式服务器的总体结构由交互对象可以划分为两个部分，一个是与用户的交互，一个是与汽车音响语音服务器的交互。与用户交互主要是来处理用户的服务请求，而与汽车音响语音的服务器的交互主要是更新已完成汽车音响语音交互服务的用户的信息。基于这种比较特殊的需求，设计中决定采用Web Service技术作为嵌入式服务器设计的基础，以此来提供我们和开发用户、汽车音响语音服务器之间的交互。下面我们从这两个部分入手来分别详细介绍他们的工作机理。

在介绍嵌入式服务器的两个部件之前，我们先简要的说明一下Web Service的工作原理。Web Service为用户的提供了标准的调用接口，定义了标准的传入参数类型和返回参数类型，这些类型信息都是由Web Service定义在嵌入式服务器上，并提供标准的Web Service服务地址。想要通过该接口来发送服务的开发人员只要在工程中加入Web Service的服务地址后，这些标准的类型信息都会下载到本地，并加入到本地工程中。这样开发人员也就能够操作和使用这些类型以及在这些类型上定义的各种方法。

3.2 语言交互部件设计

当用户在自己的工程用添加了Web Service后，就可以像本地使用对象类一样，对于相关的接口进行调用操作。调用采用同步的方式，也就是说用户必须等到Web Service返回一个结构以后才能够继续执行。当调用相关接口的时候，用户的基本的信息也就自然的通过网络发送到了嵌入式服务器端，嵌入式服务器经过对于这些的数据的处理以后会返回给用户对应的数据，这些数据包含在返回数据类型的实例中，以此来告知用户此次服务请求的结果[1]。

3.3 语言数据库接口设计

当数据通过接口传入Web Service后，接口函数会解析用户的信息，并将这些信息发送给用户数据库验证，验证后的结果会很快的返回到Web Service。通过验证后，Web Service会更根据用户的地域和级别信息发送到汽车音响语音服务器数据库以获取相应的服务器的信息。成功完成后，Web Service会向已经获取的服务器发送用户的信息，以通知服务器此用户为此次的合法授权用户。当服务器相应以后，Web Service才会认为一切的数据均已经准备完成，才把服务器的信息作为返回类型中的数据信息返回给用户。用户通过解析此数据就能够得到服务器的信息[2]。

模块通过控制合成内核其它各个算法模块来共同协作完成文本到汽车音响语音的转换工作，并通过某种统一的接口向外层提供服务。

3.4 合成器设计

“合成逻辑控制”也是系统跨平台的一些重要组成部分。它将各个算法模块与操作系统的调用完全隔离开来，不仅完成了内部核心数据结构在多线程下同步，使得系统能够同时并发处理多个请求；而且为各个算法模块提供了对于各种资源文件的访问的支持[3]。

从流程来看，汽车音响语音合成系统在完成文本到汽车音响语音数据的转化过程中可以简单分解为两个步骤的处理。文本先经过前端的语法分析和韵律分析，主要包括一些文本的预处理、语言学处理和汽车音响语音学处理，得到格式规范，携带语法层次的信息，传送到后端。后端在前端分析的结果基础上，使用特定的合成算法来生成最终的汽车音响语音数据。可据此将各个算法模块大致划分成两大类：前端模块和后端模块。

以上是用户交互部件的情况，下面我们将介绍汽车音响语音服务器交互部件。汽车音响语音服务器交互部件主要是在用户与汽车音响语音服务器结束交互的时候，汽车音响语音服务器会向Web Service发出请求，传入用户消费记录的信息。这部分对于用户来说是透明的，用户并不需要知道它的存在，可它去在记录这用户的每次消费的记录。关键数据代码如下：

class VoiceInteractiveDevice：CSTADevice

{

#region Voice Service

public void Start（）

{}

//...other voice services

#endregion

#region Call Control Service

private void MakeCall（）

{ }

//...other call control services

#endregion

#region Voice Events

public VoiceEventHandler Recognized；

//...other voice events

#endregion

#region Call Control Events

private CallControlEventHandler Established；

//...other call control events

#endregion

}

4 总结

在汽车音响语言合成服务系统内部，会为此次主叫设备所在Call对象创建一个交互设备实例，Listener的实例，因为服务的交互时通过具体的Call对象来完成的，而在Call建立的时候，实际上分配的是一个虚拟的设备，也就是说没有具体的类别和具体的汽车音响语音交互设备实例被真正的创建，这个时候汽车音响语音服务才会真正的创建所需要的交互设备对象，并把Call对象中虚拟的设备对象更新为真正的交互设备对象。创建后的交互设备对象会被保存在对应的设备实例池中，用来保存交互的状态和内容。接下来，这个实例会通过和后台汽车音响语音识别引擎的交互来满足Client的汽车音响语音服务请求。

参考文献：

[1]李禹材，左友东，郑秀清，王玲.基于Speech SDK的语音控制应用程序的设计与实现[J].计算机应用，2004，6

[2]陈素燕，刘友生.基于SAPI技术的双语混读在CAI开发中的应用[J].计算机工程与设计，2006，4

[3]宋阳，刘胜兰，张燕宏.利用SAPI5完成中文语音音素的分解[J].微计算机信息，2005，3

[作者简介]孙敏捷（1990-），男，籍贯：江苏丹阳，本科。