CN114205429A - 基于udp协议的语音包处理方法、***、设备及存储介质 - Google Patents

Abstract

本发明提出一种基于UDP协议的语音包处理方法、***、设备及存储介质，该方法包括：接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包对应的序号为连续的、且接收的所有语音包个数与预设语音包个数相等；根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；将重新排序后的语音包发送给语音识别引擎。本发明实施例避免了语音包顺序错乱，有效提高目标语音传输的可靠性。

Description

基于UDP协议的语音包处理方法、***、设备及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种基于UDP协议的语音包处理方法、***、设备及存储介质。

背景技术

目前语音导航机器人、外呼机器人、语音机器人助手已经越来越多的应用在各行各业中，极大的降低了相关企业在相关业务的运营成本，客服机器人可以做到7乘以24小时全天候服务。当前语音机器人发送语音流语音包的方式一般都为HTTP的方式，从客户端传入服务端再到引擎，引擎将结果返回服务端，服务端再返回到客户端。该方案在客户端数量较少的情况下可以实现简单的语音机器人相关功能，但是对于实时性要求比较高的场景下，HTTP表示面向连接的协议，要传输数据必须先进行连接，就是常常说的“三次握手”，握手成功建立之后，才能进行数据的传输交互。

由于单个客户端发送语音包是一个非常高频的请求，大量HTTP请求会占用大量的带宽，在多个客户端同时请求的情况下，延迟会有明显增加。因此这种方式虽然能保证语音包的顺序性，但是在客户端请求数量较多的情况下，语音包发送的延迟情况就会成为一个比较突出的问题，客户的满意度同时也会受到影响。常见的解决办法就是用UDP协议代替TCP协议进行语音包的发送。

但是UDP是一种不可靠的传输协议，其发送语音包的时候，是无法保证语音包到达的顺序的，如果错误的语音包顺序发送到语音识别引擎，会导致错误的识别结果。

发明内容

本发明提供一种基于UDP协议的语音包处理方法、***、设备及存储介质，其主要目的在于避免语音包顺序错乱，有效提高目标语音传输的可靠性。

第一方面，本发明实施例提供一种基于UDP协议的语音包处理方法，该方法包括：

接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；

根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包个数与预设语音包个数相等；

根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；

将重新排序后的语音包发送给语音识别引擎。

优选地，所述预设语音配置信息包括起始序号和终止序号，所述语音包还包括数据信息，所述根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，包括：

若所述语音包对应的序号位于所述起始序号和所述终止序号之间，且所述语音包对应的数据信息不为空，且所述语音包对应的序号与接收到的语音包对应的序号不重复，则判断所述语音包为正常状态。

优选地，还包括：

将接收的语音包对应的序号，按照大小将接收的语音包缓冲至环形消息队列中；

从所述环形消息队列中顺序提取接收的语音包，并通过所述环形消息队列同步缓冲接收到的新语音包，直到语音包接收完毕；

若接收的所有语音包个数小于所述预设语音包个数，或者，接收的所有语音包对应的序号不连续，则判断发生丢包。

优选地，还包括：

若预设时间段内没有接收到丢失的语音包，则将丢失的语音包对应的序号发送给所述客户端，以使得所述客户端根据序号发送相应的语音包。

优选地，所述将重新排序后的语音包发送给语音识别引擎，包括：

根据所述客户端发送语音包的频率、预设实时性要求和所述语音识别引擎支持单个语音包的大小，确定合并个数；

以所述合并个数为最大上限，将重新排序后的语音包进行合并，得到合并后的语音包；

将合并后的语音包发送给所述语音识别引擎。

优选地，还包括：

若所述语音包对应的序号小于所述起始序号，或，所述语音包对应的序号大于所述终止序号，或，所述语音包对应的数据信息为空，则判断所述语音包为缺失状态；

将所述语音包对应的序号发送给客户端，并删除所述语音包，以使得所述客户端根据所述语音包对应的序号，重新发送相应语音包，重复上述过程，直到新语音包为正常状态。

优选地，还包括：

若所述语音包对应的序号与接收到的语音包对应的序号存在重复，则判断所述语音包为重复状态，删除所述语音包。

第二方面，本发明实施例提供一种基于UDP协议的语音包处理***，包括：

接收模块，用于接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；

判断模块，用于根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包个数与预设语音包个数相等；

排序模块，用于根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；

识别模块，用于将重新排序后的语音包发送给语音识别引擎。

第三方面，本发明实施例提供一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述基于UDP协议的语音包处理方法的步骤。

第四方面，本发明实施例提供一种计算机存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述基于UDP协议的语音包处理方法的步骤。

本发明提出的一种UDP协议的语音包处理方法、***、设备及存储介质，将目标语音拆分成多个语音包，通过将每个接收到的语音包和预设语音配置信息进行比较，以确保每次接收到的语音包都是正常状态；再根据语音包对应的序号进行重新排序，保证重新排序后的语音包不会顺序错乱。本发明实施例既保证了语音包传输的可靠性，有效保证了语音包的高效性，并且支持的并发语音包数量比TCP传输方式高，提高了数据传输的实时性。

附图说明

图1为本发明实施例提供的一种基于UDP协议的语音包处理方法的应用场景示意图；

图2为本发明实施例提供的一种基于UDP协议的语音包处理方法的流程图；

图3为本发明实施例提供的一种基于UDP协议的语音包处理***的结构示意图；

图4为本发明实施例中提供的一种计算机设备的结构示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

图1为本发明实施例提供的一种基于UDP协议的语音包处理方法的应用场景示意图，如图1所示，用户在客户端上传目标语音，客户端将目标语音拆分成为多个语音包，并且根据拆分出的语音包，计算出目标语音对应的预设语音配置信息，客户端先将预设语音配置信息和拆分出的语音包发送给服务端，服务端接收该拆分出的语音包和预设语音配置信息后，执行该一种基于UDP协议的语音包处理方法，得到重新排序后的语音包，进而将重新排序后的语音包发送给语音识别引擎。

需要说明的是，服务端可以用独立的服务器或者是多个服务器组成的服务器集群来实现。客户端可为智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此。客户端和服务端、服务端和语音识别引擎可以通过蓝牙、USB(Universal Serial Bus，通用串行总线)或者其他通讯连接方式进行连接，本发明实施例在此不做限制。

图2为本发明实施例提供的一种基于UDP协议的语音包处理方法的流程图，该方法包括：

本发明实施例的执行主体为服务端，当客户端接收到触发指令时，向服务端发送目标语音，具体发送方法是将目标语音拆分成多个语音包，在语音包开始发送时，会有一个sessionbegin的标识，表示语音包开始发送；当发送通话语音包时，标识为session in，表示语音包正在发送中；当语音包结束时，标识为session end，表示语音包发送结束。在一般情况下，语音包发送过程会经历以上3种状态，每种状态用不同的标识进行区分。通过不同的状态标识对目标语音发送过程中的各种状态进行表示，以便于相关操作人员的使用。

一般而言，客户端通过UDP协议向服务端发送目标语音，目标语音为具有一定时长的语音流，为了便于处理，客户端将目标语音拆分为一段段语音片段，然后将语音片段转化问文字、压缩编码等处理，将语音片段转化为语音包，每个语音片段称作为一个语音包，语音包中包括该语音片段在目标语音中所在的位置，本发明实施例中用序号表示。

另外，客户端向服务端发送语音包之前，会先发送预设语音配置信息，预设语音配置信息中包括拆分出来的语音包的各种基础信息，比如拆分出来的语音包的个数和语音包的起始序号、序号递增量和终止序号等等信息，一般而言，对语音包按照顺序递增进行编号，根据语音包的起始序号和序号递增量，服务端就可以得出每个语音包的序号，以便对接收到的语音包进行验证。

S210，接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；

在客户端向服务端发送语音包的过程中，服务端接收到发送过来的语音包，该语音包中包括对应的序号，该序号表明了该语音包对应的片段在目标语音中所在的位置，根据该序号有利于后续的语音包顺序重新调整。

本发明实施例中，客户端将目标语音进行拆分时，一般第一个语音包和最后一个语音包为静止包，也就是其包含的内容是无效的，中间的语音包所包含的内容是有效的，因此客户端在进行语音包的发送时，会忽略掉排在最前的语音包和排在最后的语音包，而只发送处于中间位置的语音包。

S220，根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包个数与预设语音包个数相等；

由于根据预设语音配置信息就可以得出每个语音包的序号、语音包对应的序号最大值和语音包对应的序号最小值，对于当前接收到的语音包，先从该语音包的序号判断该语音包是否正确，然后从该语音包所携带的数据是否为空进行判断，然后再判断该语音包的序号与之前接收到的语音包序号是否重复等等，以此来进行接收到的语音包是否为正常状态的判断，如果当前接收到的语音包是正常状态的，才会继续接收下一个语音包，然后再对接收到的语音包进行是否是正常状态的判断，如果是正常状态，接收该语音包，直到接收完所有客户端发送的语音包。在具体实施过程中，客户端发送完所有的语音包后，会向服务端发送结束指令，服务端接收到该结束指令后，即知道语音包接收完毕。

还需要说明的是，预设语音配置信息中所包含的是与语音包有关的基础配置信息，该预设语音配置信息可以是客户端将其与语音包一起发送给服务端的，也可以是根据事先约定人为设置在服务端的，具体根据实际情况进行确定，本发明实施例在此不做具体的限定。

服务端接收到所有语音包后，如果接收到的语音包对应的序号是连续且完整的，并且接收到的语音包个数也与预设语音包个数相同，则说明接收到的语音包是正常的。

还需要说明的是，预设语音包个数可以是客户端在发送语音包时一起发送过去给服务端的，也可以是按照事先约定人为设置在服务端的，还可以是包含在预设语音配置信息中的，具体根据实际情况进行确定，本发明实施例在此不做具体的限定。

S230，根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；

由于UDP协议在传输时不用与对方设备提前进行连接，也不用发送的数据进行确认，因此UDP协议提供的是不可靠的数据传输，本发明实施例中通过预设语音配置信息可以确保接收到的语音包是完整的和可靠的，但是接收到的语音包不一定是按照顺序排列的，这样再后续将接收到的语音包发送给语音识别引擎时是乱序的。因此，本发明实施例中在语音包中设置序号标志位，根据语音包中所包含的序号来确定其在目标语音的位置，对接收到的语音包进行重新排序，得到重新排序后的语音包。

S240，将重新排序后的语音包发送给语音识别引擎。

将重新排序后的语音包，发送给语音识别引擎。具体发送方法可以为：基于TCP传输协议的无线网络语音包发送方法、基于蓝牙传输的语音包发送方法、以及目前市面上对TCP协议进行优化后的某些发送方法，这些发送方法虽然协议比UDP复杂一些，但是由于存在数据发送后的确认行为，其可靠性比较高，稳定性也较好。

语音识别引擎可以为目前市面上主流的科大引擎和阿里引擎等，基于该语音识别引擎，在具体实施时创建一个线程来进行UDP语音包的发送，因为目前市面上主流的语音识别引擎并不支持多线程并发操作。

本发明实施例提供一种基于UDP协议的语音包处理方法，将目标语音拆分成多个语音包，通过将每个接收到的语音包和预设语音配置信息进行比较，以确保每次接收到的语音包都是正常状态；再根据语音包对应的序号进行重新排序，保证重新排序后的语音包不会顺序错乱。本发明实施例既保证了语音包传输的可靠性，有效保证了语音包的高效性，并且支持的并发语音包数量比TCP传输方式高，提高了数据传输的实时性。

在上述实施例的基础上，优选地，所述预设语音配置信息包括起始序号和终止序号，所述语音包还包括数据信息，所述根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，包括：

若所述语音包对应的序号位于所述起始序号和所述终止序号之间，且所述语音包对应的数据信息不为空，且所述语音包对应的序号与接收到的语音包对应的序号不重复，则判断所述语音包为正常状态。

具体地，该预设语音配置信息中包括语音包的起始序号和语音包的终止序号，一般地，语音包的序号分配从起始序号开始，下一个语音包的序号便增加1，如此，为每个语音包分配一个序号，直到分到语音包的终止序号。如果语音包的递增量不为1，那么预设语音配置信息中还包括序号变化量，该序号变化量表示相邻两个语音包之间的序号间隔，在知道起始序号、序号变化量和终止序号后，就可以计算出每个语音包对应的序号，也可以计算出所需要接收的语音包个数，即预设语音包个数。

如果当前接收的语音包对应的序号位于起始序号和终止序号之间，说明当前接收的语音包对应的序号是符合要求的，接着再判断所接收的当前语音包中所携带的数据信息是否为空，如果不为空，说明该当前语音包所携带的数据信息是正常的，如果为空，说明该当前语音包在信息发送过程中出现了故障，将该语音包对应的状态判定为非正常状态；最后再判断接收到的语音包对应的序号是否与之前接收到的语音包对应的序号重复，如果重复，说明客户端存在重复发送语音包的错误，如果不重复，说明该当前语音包是正确的。

经过以上判断，如果当前语音包序号在起始序号和终止序号之间，该当前语音包对应的数据信息不为空，并且该当前语音包对应的序号与服务端中已接收的语音包对应的序号不重复，在这三个条件都满足的情况下，判断该语音包为正常状态。

对服务端所接收的每个语音包都进行这样的判断，只有当这个语音包判断为正常状态时，才能继续接收下一个语音包，并对下一个语音包进行相同的判断。

在上述实施例的基础上，优选地，还包括：

将接收的语音包对应的序号，按照大小将接收的语音包缓冲至环形消息队列中；

从所述环形消息队列中顺序提取接收的语音包，并通过所述环形消息队列同步缓冲接收到的新语音包，直到语音包接收完毕；

若接收的所有语音包个数小于所述预设语音包个数，或者，接收的所有语音包对应的序号不连续，则判断发生丢包。

具体地，本发明实施例中，服务端将接收到的语音包用环形消息队列进行存储，在具体实施的过程中，服务端接收到当前语音包，根据该语音包的序号，将其存储至环形消息队列的相应位置处。需要说明的是，环形信息队列的总长度、每个存储节点的长度都根据预设语音配置信息进行设置，环形消息队列的总存储量即为所有语音包个数乘以每个语音包的容量，在存储时，按照序号的大小顺序，将语音包进行顺序存储在环形消息队列中。

在服务端接收完所有的语音包后，如果接收到的所有语音包个数小于预设语音包个数，那么说明在发送过程中存在语音包丢失的情况，则判定发生丢包；或者，所有接收到的语音包对应的序号不连续，或者，与发送过来的语音包对应的序号不相符，说明该语音包发生了丢包，需要根据相应的丢包处理策略进行调整。

还需要说明的是，环行消息队列是一种首尾相连的队列数据结构，遵循先进先出原则，在环形消息队列中用一组连续地址的存储单元依次存放从环形信息队列头到队列尾的元素，通过两个指针read_pos和write_pos分别指向读取位置和写入位置。

初始化环形消息队列时，令read_pos＝write_pos＝0，每当写入一个新元素时，write_pos增1；每当读取一个元素时，read_pos增1。若环形消息队列已满，不能往环形信息队列写入数据；若环形消息队列为空，则不能读取数据。判断对列是否为满的的方法是看(write_pos+1)％QUEUE_SIZE＝＝read_pos是否成立，判断环形信息队列是否为空的方法是看write_pos＝＝read_pos是否成立。

鉴于多个线程同时访问环形信息队列，需要考虑线程之间的互斥和同步问题，拟采用锁控制多个线程互斥访问环形信息队列，使用信号量控制线程之间的同步。

一段时间内只能有一个线程获得锁，当它持有锁时，其它线程要访问环形信息队列必须等待，直到前者释放锁。由此，锁可以保证多个线程互斥的访问环形信息队列。

线程从环形消息队列对数据前首先判断信号量是否大于1，若是，则从环形消息队列读数据；否则，进入等待状态，直到信号量大于1为止；线程往环形消息队列写入一个数据后，会将信号量增1，若有线程在等待，则会被唤醒。由此，信号量实现了多线程同步访问环形消息队列。

在上述实施例的基础上，优选地，还包括：

若预设时间段内没有接收到丢失的语音包，则将丢失的语音包对应的序号发送给所述客户端，以使得所述客户端根据序号发送相应的语音包。

具体地，为了避免数据的重复发送，在接收完所有的语音包后的预设时间段内，如果依然没有接收到丢失的语音包，那么就可以确认语音包确实丢失了，这样服务端就会将丢失语音包的信号发送给客户端，客户端接收到该序号后，根据该序号找到对应的语音包，并将相应的语音包发送给服务端。

在上述实施例的基础上，优选地，所述将重新排序后的语音包发送给语音识别引擎，包括：

根据所述客户端发送语音包的频率、预设实时性要求和所述语音识别引擎支持单个语音包的大小，确定合并个数；

以所述合并个数为最大上限，将重新排序后的语音包进行合并，得到合并后的语音包；

将合并后的语音包发送给所述语音识别引擎。

具体地，客户端发送语音包的频率越高，合并语音包消耗的时间就越少，对性能的影响就越小，但是合并语音包的个数不能太多，因为市面上主流的语音识别引擎对单次请求都是有一定大小限制的，过大则引擎会报错，但是合并包的数量太少，那么发送错乱语音包包的影响就会越大，因此对合并包数量的选取是一个很复杂的，需要不断调试的过程，需要根据实际情况而定。

根据客户端发送语音包的频率，可以计算出单位时间内可以发送语音包的个数，并且根据实时性要求，计算出发送目标语音所需要的时间是否满足该实时性要求，如果不满足，则需要对相互连续的语音包进行合并，至于每次需要合并几个语音包，则是根据语音识别引擎支持的单个语音包大小所决定的，合并后的语音包的大小不能大于所选择语音识别引擎支持单个语音包的大小，根据这三个方面选择出最合适的合并个数。

一般来说，合并个数与客户端发送语音包的频率和预设实时性要求成正比，与语音识别引擎支持单个语音包的大小成反比，预设实时性要求一般为客户的时效要求。

举例地，如果选取的合并个数为2，则将重新排序后的语音包中连续2个语音包进行合并，可以合并其中1处，也可以合并其中多处，具体可以根据实际需要进行确定，本发明实施例在此不做具体的限定。

进行合并后得到合并后的语音包，将该合并后的语音包发送给语音识别引擎，此处的发送方式是基于TCP协议进行发送的，TCP协议能够保证可靠的无差错传输服务，服务端在进行数据传输时需要先与语音识别引擎进行3次握手，并且发送的每个语音包都要进行确认。

本发明实施例提供的一种基于UDP协议的语音包处理方法，根据UDP发送语音包的频率、预设实时性要求和语音识别引擎支持单个语音包的大小，确定最合适的合并个数，以此对语音包进行合并，这样就可以减少发送语音包的个数。由于不是每个语音包都是请求语音识别引擎，合适把适当数量的语音包合并之后再去请求，因此可以降低的对语音识别引起请求的频率，提高了引擎服务器的承压能力。

在上述实施例的基础上，优选地，还包括：

若所述语音包对应的序号小于所述起始序号，或，所述语音包对应的序号大于所述终止序号，或，所述语音包对应的数据信息为空，则判断所述语音包为缺失状态；

将所述语音包对应的序号发送给客户端，并删除所述语音包，以使得所述客户端根据所述语音包对应的序号，重新发送相应语音包，重复上述过程，直到新语音包为正常状态。

如果接收到的当前语音包对应的序号小于起始序号，或者接收到的当前语音包对应的序号大于终止序号，则判断接收到的当前语音包为缺失状态。

由于服务端根据预设语音配置信息可以得到每个语音包的序号，以预设语音配置信息得出的每个语音包的序号为参考基准，将接收到的语音包进行对比，看该语音包的序号是否连续或者完整，如果不连续，说明接收到的语音包存在缺失的情况，通过与参考基准进行对比，就可以得出缺失的语音包的序号。

服务端将缺失的语音包序号发送给客户端，客户端接收到该缺失的语音包序号后，根据该序号，在存储发送语音包的数据仓库中进行查找，找到相同序号的语音包后，将该语音包发送给服务端，服务端接收到该语音包，再重新判断接收到的语音包的序号是否连续或者完整，如果不连续，重复该过程，直到接收到的语音包的序号完整。如果完整，则对新接收到的语音包重新进行排序，得到重新排序后的语音包。

本发明实施例通过将接收到的语音包包含的序号与预设语音配置信息中计算序号进行比对，可以判断出接收到的语音包是否缺失，如果缺失，则使得客户端重新发送，该方法服务端不用每接收到一个语音包就与客户端进行确认，而是只发送缺失语音包的序号即可，这样既保证了接收语音包的正确性，又保证了语音发送的时效性，也不会占用服务器太大的带宽。

在上述实施例的基础上，优选地，还包括：

若所述语音包对应的序号与接收到的语音包对应的序号存在重复，则判断所述语音包为重复状态，删除所述语音包。

同样地，再根据预设语音配置信息，以预设语音配置信息为参考基准，判断接收到的语音包是否有重复的序号，如果有，说明接收到的语音包存在重复，在这种情况下，则保留一个重复的语音包，删除其它重复的语音包，得到剩下的语音包，重新根据剩下的语音包的序号进行排序，得到重新排序后的语音包。

本发明实施例通过预设语音配置信息，可以预先得到所有语音包的序号，并与接收到的语音包的实际序号进行比对，可以判断出接收到的语音包是否连续或是否重复，根据判断结果重新对接收到的语音包进行优化，从而保证了接收到语音包的连续性和完整性，也保证了后续语音识别引擎相关业务的准确性。

图3为本发明实施例提供的一种基于UDP协议的语音包处理***的结构示意图，如图3所示，该***包括接收模块310、判断模块320、排序模块330和识别模块340，其中：

接收模块310用于接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；

判断模块320用于根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包个数与预设语音包个数相等；

排序模块330用于根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；

识别模块340用于将重新排序后的语音包发送给语音识别引擎。

本实施例为与上述方法实施例对应的***实施例，其具体实施过程与上述方法实施例相同，详情请参考上述方法实施例，本***实施例在此不再赘述。

在上述实施例的基础上，优选地，所述预设语音配置信息包括起始序号和终止序号，所述语音包还包括数据信息，所述根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，包括：

若所述语音包对应的序号位于所述起始序号和所述终止序号之间，且所述语音包对应的数据信息不为空，且所述语音包对应的序号与接收到的语音包对应的序号不重复，则判断所述语音包为正常状态。

在上述实施例的基础上，优选地，还包括：缓冲模块、提取模块和丢包模块，其中：

所述缓冲模块用于将接收的语音包对应的序号，按照大小将接收的语音包缓冲至环形消息队列中；

所述提取模块用于从所述环形消息队列中顺序提取接收的语音包，并通过所述环形消息队列同步缓冲接收到的新语音包，直到语音包接收完毕；

所述丢包模块用于若接收的所有语音包个数小于所述预设语音包个数，或者，接收的所有语音包对应的序号不连续，则判断发生丢包。

在上述实施例的基础上，优选地，还包括重发模块，其中：

所述重发模块用于若预设时间段内没有接收到丢失的语音包，则将丢失的语音包对应的序号发送给所述客户端，以使得所述客户端根据序号发送相应的语音包。

在上述实施例的基础上，优选地，所述识别模块包括个数确定单元、合并单元和发送单元，其中：

所述个数确定单元用于根据所述客户端发送语音包的频率、预设实时性要求和所述语音识别引擎支持单个语音包的大小，确定合并个数；

所述合并单元用于以所述合并个数为最大上限，将重新排序后的语音包进行合并，得到合并后的语音包；

所述发送单元用于将合并后的语音包发送给所述语音识别引擎。

在上述实施例的基础上，优选地，还包括缺失判断模块和缺失补救模块，其中：

所述缺失判断模块用于若所述语音包对应的序号小于所述起始序号，或，所述语音包对应的序号大于所述终止序号，或，所述语音包对应的数据信息为空，则判断所述语音包为缺失状态；

所述缺失补救模块用于将所述语音包对应的序号发送给客户端，并删除所述语音包，以使得所述客户端根据所述语音包对应的序号，重新发送相应语音包，重复上述过程，直到新语音包为正常状态。

在上述实施例的基础上，优选地，还包括删除重复模块，其中：

所述删除重复模块用于若所述语音包对应的序号与接收到的语音包对应的序号存在重复，则判断所述语音包为重复状态，删除所述语音包。

上述基于UDP协议的语音包处理***中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

图4为本发明实施例中提供的一种计算机设备的结构示意图，该计算机设备可以是服务器，其内部结构图可以如图4所示。该计算机设备包括通过***总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括计算机存储介质、内存储器。该计算机存储介质存储有操作***、计算机程序和数据库。该内存储器为计算机存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储执行基于UDP协议的语音包处理方法过程中生成或获取的数据，如语音包、预设语音包配置信息。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于UDP协议的语音包处理方法。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例中的基于UDP协议的语音包处理方法的步骤。或者，处理器执行计算机程序时实现基于UDP协议的语音包处理***这一实施例中的各模块/单元的功能。

在一实施例中，提供一计算机存储介质，该计算机存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中基于UDP协议的语音包处理方法的步骤。或者，该计算机程序被处理器执行时实现上述基于UDP协议的语音包处理***这一实施例中的各模块/单元的功能。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于UDP协议的语音包处理方法，其特征在于，包括：

接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；

根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包对应的序号为连续的、且接收的所有语音包个数与预设语音包个数相等；

根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；

将重新排序后的语音包发送给语音识别引擎。

2.根据权利要求1所述的基于UDP协议的语音包处理方法，其特征在于，所述预设语音配置信息包括起始序号和终止序号，所述语音包还包括数据信息，所述根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，包括：

若所述语音包对应的序号位于所述起始序号和所述终止序号之间，且所述语音包对应的数据信息不为空，且所述语音包对应的序号与接收到的语音包对应的序号不重复，则判断所述语音包为正常状态。

3.根据权利要求1所述的基于UDP协议的语音包处理方法，其特征在于，还包括：

将接收的语音包对应的序号，按照大小将接收的语音包缓冲至环形消息队列中；

从所述环形消息队列中顺序提取接收的语音包，并通过所述环形消息队列同步缓冲接收到的新语音包，直到语音包接收完毕；

若接收的所有语音包个数小于所述预设语音包个数，或者，接收的所有语音包对应的序号不连续，则判断发生丢包。

4.根据权利要求3所述的基于UDP协议的语音包处理方法，其特征在于，还包括：

若预设时间段内没有接收到丢失的语音包，则将丢失的语音包对应的序号发送给所述客户端，以使得所述客户端根据序号发送相应的语音包。

5.根据权利要求1所述的基于UDP协议的语音包处理方法，其特征在于，所述将重新排序后的语音包发送给语音识别引擎，包括：

根据所述客户端发送语音包的频率、预设实时性要求和所述语音识别引擎支持单个语音包的大小，确定合并个数；

以所述合并个数为最大上限，将重新排序后的语音包进行合并，得到合并后的语音包；

将合并后的语音包发送给所述语音识别引擎。

6.根据权利要求1至5任一所述的基于UDP协议的语音包处理方法，其特征在于，还包括：

若所述语音包对应的序号小于所述起始序号，或，所述语音包对应的序号大于所述终止序号，或，所述语音包对应的数据信息为空，则判断所述语音包为缺失状态；

将所述语音包对应的序号发送给客户端，并删除所述语音包，以使得所述客户端根据所述语音包对应的序号，重新发送相应语音包，重复上述过程，直到新语音包为正常状态。

7.根据权利要求6所述的基于UDP协议的语音包处理方法，其特征在于，还包括：

若所述语音包对应的序号与接收到的语音包对应的序号存在重复，则判断所述语音包为重复状态，删除所述语音包。

8.一种基于UDP协议的语音包处理***，其特征在于，包括：

接收模块，用于接收语音包，所述语音包包括语音包对应的序号，语音包由目标语音拆分而成；

判断模块，用于根据所述语音包对应的序号和预设语音配置信息，判断所述语音包是否为正常状态，若为正常状态，调整接收的所有语音包个数，重复上述过程，直到接收的所有语音包个数与预设语音包个数相等；

排序模块，用于根据接收的所有语音包对应的序号，对接收的所有语音包进行重新排序，获取重新排序后的语音包；

识别模块，用于将重新排序后的语音包发送给语音识别引擎。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述基于UDP协议的语音包处理方法的步骤。

10.一种计算机存储介质，所述计算机存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述基于UDP协议的语音包处理方法的步骤。

Images