CN116170423A - 基于nodejs中间件对讲录音编解码系统及方法 - Google Patents

Abstract

本申请涉及一种基于nodejs中间件对讲录音编解码系统及方法，所述方法包括：客户端获取声音传感器的使用权限；调用声音传感器采用单通道的模式采集原始pcm音频数据；nodejs中间件将原始pcm音频数据合并与压缩、以及进行进一步压缩封装排序，得到处理后的音频包，并发送至服务端；服务端接收处理后的音频包，检验是否符合规范，将符合规范的音频包进行接收；服务端将处理后的音频包发送至nodejs中间件进行接收时，对处理后的音频包进行解压还原，得到pcm音频包，并将pcm音频包进行排序合并，通过socket连接发送至客户端，并通过客户端的播放器进行播放。通过本申请实施例，提高了音频数据传输的过程中的稳定性，进而提高通话的质量和稳定性。

Description

基于nodejs中间件对讲录音编解码系统及方法

技术领域

本申请涉及nodejs中间件通信技术领域，尤其是涉及基于nodejs中间件对讲录音编解码系统及方法。

背景技术

对讲机是一种双向移动通信工具，在不需要任何网络支持的情况下，就可以通话，没有话费产生，对讲机应用领域很广，主要应用在公安、民航、运输、水利、铁路、制造、建筑、服务等行业，用于团体成员间的联络和指挥调度，以提高沟通效率和提高处理突发事件的快速反应能力。随着对讲机进入民用市场，人们外出旅游、购物也开始越来越多地使用对讲机。

随着互联网的发展，传统的对讲机已经不能满足人们的需求，传统的对讲机的通话距离受限制，当通话超过一定距离，通话质量得不到保障。

发明内容

为了提高对讲机通话的质量和稳定性，本申请提供基于nodejs中间件对讲录音编解码系统及方法。

在本申请的第一方面提供了一种基于nodejs中间件对讲录音编解码系统，所述系统包括：数据采集单元、数据处理单元和数据接收单元；所述数据采集单元在客户端上运行，所述数据处理单元和所述数据接收单元均在nodejs中间件上运行；所述客户端与所述nodejs中间件建立socket连接，用于将音频数据发送至所述nodejs中间件，所述nodejs中间件，用于将所述音频数据进行处理后发送至服务端。

通过采用上述技术方案，将客户端采集到的音频数据发送至nodejs中间件，通过nodejs中间件对音频数据的处理，持续向服务端发送处理过后的音频数据，保证音频数据传输的可靠稳定，提高通话的质量和稳定性。

可选的，所述数据采集单元由声音传感器组成，用于通过所述声音传感器将所述音频数据采集至所述客户端中。

通过采用上述技术方案，客户端上的数据采集单元由声音传感器组成，可以通过声音传感器来对音频数据进行收集。

可选的，所述数据处理单元包括合并压缩模块、分包解码压缩模块、封装排序模块以及发送模块，所述合并压缩模块、分包解码压缩模块、封装排序模块、发送模块分别进行数据连接；

所述合并压缩模块，用于将所述数据采集单元采集到的原始pcm音频数据进行偏移量计算，并将所述原始pcm音频数据进行合并压缩，得到合并压缩的音频数据；

所述分包解码压缩模块，用于将所述合并压缩的音频数据转换成指定采样率、采样数的音频数据；根据预置的分包算法将转换后的音频数据划分成pcm音频包，并根据opus编码算法将划分后的pcm音频包进一步转换成opus格式的音频包；

所述封装排序模块，用于将所述opus格式的音频包通过rtp进行封装，添加长度为8个字节的数据包头，得到封装完后的音频包，所述8个字节的数据包头由4个字节的数据长度和4个字节的数据类型组成；将所述封装完后的音频包按照固定大小并通过分包机制进行分包排序，得到rtp格式的音频包；

所述发送模块，用于将所述rtp格式的音频包通过定时算法按照固定的时间间隔发送到服务端。

通过采用上述技术方案，通过nodejs中间件上的数据处理单元对原始的音频数据进行合并压缩、分包解码压缩、封装排序一系列的数据处理，使得在不影响音频质量的前提下，压缩音频数据，减轻服务端的负载量。

可选的，所述数据接收单元包括解码解压缩模块、数据拼接模块以及播放模块组成，所述解码解压缩模块、数据拼接模块和播放模块依次进行数据连接；

所述解码解压缩模块，用于将所述rtp格式的音频包去掉8个字节长度的数据包头和12字节长度的rtp头，以将所述rtp格式的音频包还原为所述opus格式的音频包，通过预置的opus解码算法将所述opus格式的音频包解压缩为pcm原始音频包；

所述数据拼接模块，用于将所述pcm原始音频包根据音频包序号按照顺序依次进行合并，得到合并后的音频包；

所述播放模块，用于通过播放器将所述合并后的音频包通过客户端进行播放。

通过采用上述技术方案，通过nodejs中间件上的数据接收单元对接收到的音频数据进行解码解压缩以及数据拼接合并处理，以得到合并后的音频包，再通过播放模块将合并后的音频包进行播放。

在本申请的第二方面提供了一种基于nodejs中间件对讲录音编解码方法，该方法应用于基于nodejs中间件对讲录音编解码系统，所述系统包括客户端、nodejs中间件以及服务端，所述客户端、nodejs中间件和服务端依次进行数据连接，所述方法包括：

所述客户端获取声音传感器的使用权限；调用所述声音传感器采用单通道的模式进行音频流的采集，得到采集的原始pcm音频数据；

所述nodejs中间件通过所述数据处理单元将所述原始pcm音频数据合并与压缩，得到压缩的音频数据，并将所述压缩的音频数据进行进一步压缩封装排序，得到处理后的音频包，所述nodejs中间件将所述处理后的音频包发送至服务端；

所述服务端接收所述处理后的音频包，检验所述处理后的音频包是否符合规范，若符合规范则进行接收，若不符合规范则断开连接；

所述服务端将所述处理后的音频包发送至nodejs中间件进行接收时，所述数据接收单元对处理后的音频包进行接收，所述数据处理单元将所述处理后的音频包进行解压还原，得到pcm音频包，并将所述pcm音频包进行排序合并，通过socket连接发送给其他客户端，并通过客户端的播放器进行播放。

通过采用上述技术方案，将客户端采集到的音频数据发送至nodejs中间件，通过nodejs中间件对音频数据进行编解码后，得到音频包，并持续向服务端发送音频包，保证音频数据传输的可靠稳定，提高通话的质量和稳定性。

可选的，所述nodejs中间件，通过所述数据处理单元将所述原始pcm音频数据合并与压缩，得到压缩的音频数据，包括：所述nodejs中间件通过所述数据处理单元将所述原始pcm音频数据压缩转换为指定采样率以及采样位数的pcm音频数据，通过分包机制将所述pcm音频数据划分为固定大小的音频包，得到压缩的音频数据。

通过采用上述技术方案，将采集到的原始pcm音频数据转换成指定采样率以及采样位数的pcm音频数据，可以在不影响音频质量的情况下，压缩音频数据，减轻服务端的负载量。

可选的，所述将所述压缩的音频数据进行进一步压缩封装排序，得到处理后的音频包，包括：所述nodejs中间件将所述压缩的音频数据通过opus编码压缩，并将所述pcm音频数据转换为opus格式的音频包，通过rtp将所述opus格式的音频包进行封装排序，得到处理后的音频包。

通过采用上述技术方案，将压缩的音频数据在nodejs中间件中，通过opus进行进一步编码压缩，以转换成数据量更小的高保真opus格式的音频包，opus是一个高保真，适合在网络中传输的语音编码格式，相对于其它编码格式来说，保真性更好。

可选的，所述通过rtp将所述opus格式的音频包进行封装排序，包括：所述nodejs中间件将所述opus格式的音频包通过rtp添加长度为8个字节的数据包头，并按照固定大小通过分包机制进行分包封装排序，得到处理后的音频包，所述8个字节由4个字节的数据长度和4个字节的数据类型组成。

通过采用上述技术方案，将opus格式的音频包按照固定大小通过分包机制进行分包封装排序，以实现将音频包都处理成标准格式，并进行实时传输。

可选的，所述将所述处理后的音频包发送至所述服务端，包括：所述nodejs中间件将所述处理后的音频包进行分包，并按照预置的时间间隔持续将所述处理后的音频包发送至服务端。

通过采用上述技术方案，将处理后的音频包进行分包，并按照预置的时间间隔持续发送，可以实现实时传输，降低传输中的延迟。

可选的，所述数据处理单元将所述处理后的音频包进行解压还原，得到pcm音频包，包括：所述数据处理单元将所述处理后的音频包去掉包头和rtp头，还原为opus格式的音频包，根据opus解码算法转换为指定采样率以及采样数的pcm音频包，得到pcm音频包。

通过采用上述技术方案，将编码压缩后的音频包还原为opus格式的音频包，并根据opus解码算法进行转换得到pcm音频包，以使客户端对pcm音频包进行播放。

在本申请的第三方面提供了一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行上述的方法步骤。

在本申请的第四方面提供了一种电子设备，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行上述的方法步骤。

综上所述，本申请包括以下至少一种有益技术效果：

1.客户端采集到的音频数据发送至nodejs中间件，通过nodejs中间件对音频数据进行编解码后，得到音频包，并持续向服务端发送音频包，保证音频数据传输的可靠稳定，提高通话的质量和稳定性；

2.通过nodejs中间件上的数据处理单元对原始的音频数据进行合并压缩、分包解码压缩、封装排序一系列的数据处理，使得在不影响音频质量的前提下，压缩音频数据，减轻服务端的负载量；

3.将处理后的音频包进行分包，并按照预置的时间间隔持续发送，可以实现实时传输，降低传输中的延迟。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种基于nodejs中间件对讲录音编解码系统的结构示意图；

图2是本申请实施例提供的一种基于nodejs中间件对讲录音编解码系统的数据处理单元的模块示意图；

图3是本申请实施例提供的一种基于nodejs中间件对讲录音编解码系统的数据接收单元的模块示意图；

图4是本申请实施例提供的一种基于nodejs中间件对讲录音编解码方法的流程示意图；

图5是本申请实施例提供的一种电子设备的结构示意图。

附图标记说明：1000、电子设备；1001、处理器；1002、通信总线；1003、用户接口；1004、网络接口；1005、存储器。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。

在本申请实施例的描述中，“示性的”、“例如”或者“举例来说”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示性的”、“例如”或者“举例来说”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示性的”、“例如”或者“举例来说”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，单独存在B，同时存在A和B这三种情况。另外，除非另有说明，术语“多个”的含义是指两个或两个以上。例如，多个系统是指两个或两个以上的系统，多个屏幕终端是指两个或两个以上的屏幕终端。此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

下面结合具体的实施例对本申请进行详细说明。

请参见图1，图1是本申请实施例提供的一种基于nodejs中间件对讲录音编解码系统的结构示意图。

在一个实施例中，提出了一种基于nodejs中间件对讲录音编解码系统，该系统包括：数据采集单元、数据处理单元和数据接收单元，数据采集单元在客户端上运行，数据处理单元和数据接收单元均在nodejs中间件上运行。

其中，数据采集单元由声音传感器组成，通过声音传感器进行音频数据的采集，将采集得到的音频数据传输至客户端中，该声音传感器与客户端中的播放器配合使用，数据采集单元在客户端与nodejs中间件连接成功后，人员点击对讲机按钮，此时声音传感器开始进行实时录音采集音频数据，并实时将采集到的音频数据进行传输来实现实时对讲。

请参见图2，图2是本申请实施例提供的一种基于nodejs中间件对讲录音编解码系统的数据处理单元的模块示意图。

数据处理单元，包括合并压缩模块、分包解码压缩模块、封装排序模块以及发送模块，其中合并压缩模块、分包解码压缩模块、封装排序模块、发送模块依次进行数据连接。

合并压缩模块，用于将数据采集单元采集到的原始pcm音频数据进行偏移量计算，并将原始pcm音频数据进行合并压缩，得到合并压缩的音频数据。

分包解码压缩模块，用于将合并压缩的音频数据转换成指定采样率、采样数的音频数据；根据预置的分包算法将转换后的音频数据划分成pcm音频包，并根据opus编码算法将划分后的pcm音频包进一步转换成opus格式的音频包。

封装排序模块，用于将opus格式的音频包通过rtp进行封装，添加长度为8个字节的数据包头，得到封装完后的音频包，其中8个字节是由4个字节的数据长度和4个字节的数据类型组成；将封装完后的音频包按照固定大小并通过分包机制进行分包排序。

发送模块，用于将分包后的音频数据通过定时算法按照固定的时间间隔发送rtp格式的音频包到服务端。

通过上述数据采集单元采集到音频数据，并将音频数据通过数据处理单元进行数据的处理，实现了语音传输至服务端的功能。

请参见图3，图3是本申请实施例提供的一种基于nodejs中间件对讲录音编解码系统的数据接收单元的模块示意图。

数据接收单元包括解码解压缩模块、数据拼接模块以及播放模块组成，其中解码解压缩模块、数据拼接模块和播放模块依次进行数据连接。

其中解码解压缩模块，用于将rtp格式的音频包去掉8个字节长度的数据包头和12字节长度的rtp头，以将rtp格式的音频包还原为所述opus格式的音频包，通过预置的opus解码算法将opus格式的音频包解压缩为pcm原始音频包。

数据拼接模块，用于将pcm原始音频包根据音频包序号按照顺序依次进行合并，得到合并后的音频包；

播放模块，用于通过播放器将合并后的音频包通过客户端进行播放。

通过上述数据接收单元对音频数据进行解码压缩以及拼接播放的处理，实现了nodejs实时对讲音频数据播放的功能。

在一个实施例中，请参见图4，特提出了一种基于nodejs中间件对讲录音编解码的方法的流程示意图。该方法主要应用于基于nodejs中间件对讲录音编解码系统中，该系统包括客户端、nodejs中间件以及服务端，客户端、nodejs中间件和服务端依次进行数据连接，具体的方法包括：

步骤10：客户端获取声音传感器的使用权限；调用声音传感器采用单通道的模式进行音频流的采集，得到采集的原始pcm音频数据。

客户端在本申请实施例中理解为与服务器对应，并为客户提供本地服务的程序。

客户端上的数据采集单元由声音传感器组成，用于通过声音传感器将采集到的音频数据采集至客户端中。

进一步地，在客户端采集音频数据或者在播放音频数据之前，需要确保客户端与nodejs中间件之间建立socket连接，并且使得客户端相应的连接地址缓存在nodejs中间件中。如果客户端与nodejs中间件建立连接失败，则会提示错误信息。因此，客户端与nodejs中间件建立连接是nodejs中间件实时对讲录音编解码运行的前提。

示例性地，数据采集单元在客户端上运行，数据采集单元在客户端与nodejs中间件连接成功后，通过通过getUserMedia方法获取声音传感器的访问权限，判断是否允许访问声音传感器权限，若不允许访问则提示错误信息；若允许访问，则调用声音传感器采用单通道的模式进行音频流的采集，得到采集的原始pcm音频数据。

步骤20：nodejs中间件通过数据处理单元将原始pcm音频数据合并与压缩，得到压缩的音频数据，并将压缩的音频数据进行进一步压缩封装排序，得到处理后的音频包，nodejs中间件将处理后的音频包发送至服务端。

nodejs中间件在本申请实施例中可以理解为，封装在程序中处理请求的功能，nodejs中间件位于服务器的操作系统上，管理计算机资源和网络通讯。nodejs中间件实际就是在进入具体的数据处理前，对数据进行过滤等处理。

可选的，在上述各实施例的基础上，作为一种可选的实施例，nodejs中间件通过数据处理单元将原始pcm音频数据合并与压缩，得到压缩的音频数据，并将压缩的音频数据进行进一步压缩封装排序，得到处理后的音频包，nodejs中间件将处理后的音频包发送至服务端的步骤，还包括以下步骤：

步骤201：nodejs中间件将原始pcm音频数据压缩转换为指定采样率以及采样位数的pcm音频数据，通过分包机制将所述pcm音频数据划分为固定大小的音频包，得到压缩的音频数据。

示例性地，nodejs中间件通过audioContext和audioprocess方法获取原始pcm音频数据，该原始pcm音频数据为采样率为48000，数据为浮点型32位的pcm音频数据流，占用的资源较大，原始的pcm音频流是二维数组。通过偏移量计算，将二维的pcm音频数据转换为一体，达到合并压缩的目的。nodejs中间件将音频数据先转换为采样率为8000，采样数为16位整型的pcm音频数据。然后按照预置的分包算法将该转换后的音频数据划分为480长度的16位整型的压缩的音频数据。将采集到的原始的pcm音频转换成指定采样率、采样数的音频数据，是为了在不影响音频质量的前提下压缩音频数据，可以减轻服务端的负载量。

步骤202：nodejs中间件将压缩的音频数据通过opus编码压缩，并将pcm音频数据转换为opus格式的音频包。

示例性地，nodejs中间件将压缩的音频数据通过opus编码进行进一步压缩，并将pcm音频数据转换为数据量更小的高保真opus格式的音频包。opus是一个高保真的适合在网络中传输的语音编码格式，相对于其它编码格式来说，保真性更好。在本申请实施例中采用但不限于采用opus编码算法进行进一步压缩，在另一可行实施例中也可以采用其他编码算法进行压缩。

步骤203：nodejs中间件将opus格式的音频包通过rtp添加长度为8个字节的数据包头，并按照固定大小通过分包机制进行分包封装排序，得到处理后的音频包。

nodejs中间件对opus格式的音频包通过rtp添加长度为8个字节的数据包头，该8个字节的数据包头由4个字节的数据长度和4个字节的数据类型组成，并按照固定大小通过分包机制进行分包封装排序，得到处理后的音频包。

步骤204：nodejs中间件将处理后的音频包发送至服务端。

示例性地，nodejs中间件将处理后的音频包，按照预置的时间间隔持续发送至服务端，可以实现实时传输，降低传输中的延迟。

步骤30：服务端接收处理后的音频包，检验处理后的音频包是否符合规范。

示例性地，服务端在接收到处理后的音频包后，判断处理后的音频包是否符合预置的标准。在本申请实施例中预置的标准可以为，数据包为4个字节长度、数据包类型为4个字节长度以及rtp包头为12个字节长度。若处理后的音频包符合预置的标准，则进行接收，同时服务端将符合预置的标准的音频包转发至nodejs中间件；若处理后的音频包不符合预置的标准，则断开连接。在本申请实施例中，可以设置多个nodejs中间件，与服务端建立连接，并进行音频包的接收，可以实现一端对讲，多端收听的功能。

步骤40:服务端将符合规范的音频包发送至nodejs中间件，nodejs中间件将符合规范的音频包进行解压还原，并进行排序合并，将合并后的音频包发送至客户端进行播放。

nodejs中间件的数据处理单元将符合规范的音频包进行解码解压缩，将符合规范的音频包去掉8个字节长度的数据包头和12字节长度的rtp头,将符合规范的音频包还原为opus格式的音频包，将去掉包头和rtp头的opus格式的音频包通过opus解码算法进行解压缩转换为采样率为8000，采样位数为16位整型的固定大小的pcm音频包，将pcm音频包根据音频包序号按照顺序依次进行合并，将合并后的音频包发送至客户端，以使客户端的播放器对该音频包进行播放，直到将其播放结束。

本申请的实施原理为：客户端与nodejs中间件建立socket连接，使用getUserMedia和AudioContext方法获取访问声音传感器的权限，然后调用声音传感器采用单通道的模式对原始pcm音频数据进行采集。nodejs中间件通过数据处理单元将原始pcm音频数据合并与压缩，将其转换为指定采样率以及采样位数的pcm音频数据，通过分包机制将pcm音频数据划分为固定大小的音频包，通过opus编码压缩将pcm音频数据转换为opus格式的音频包，再通过rtp实现将opus压缩后的音频包封装排序，并按照预置的时间间隔持续发送至服务端。服务端接收到数据处理单元处理后的数据，检验处理后的音频包是否符合规范，若符合则进行接收并转发，若不符合则断开连接。当服务端将rtp音频包传输至nodejs中间件进行接收时，将符合规范的音频包去掉包头和rtp头，还原为opus格式的音频包，然后用过opus解码算法转换为指定采样率以及采样数的pcm音频包，然后发送到客户端，客户端通过数据拼接将转换后的pcm音频包进行排序合并，通过客户端的播放器进行播放。

需要说明的是：上述实施例提供的系统在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的系统和方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本申请实施例还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述所示实施例所述的一种基于nodejs中间件对讲录音编解码方法，具体执行过程可以参加图1所示实施例的具体说明，在此不进行赘述。

请参见图5，为本申请实施例提供了一种电子设备的结构示意图。所述电子设备为客户端或nodejs中间件或服务端，如图5所示，所述电子设备1000可以包括：至少一个处理器1001，至少一个网络接口1004，用户接口1003，存储器1005，至少一个通信总线1002。

其中，通信总线1002用于实现这些组件之间的连接通信。

其中，用户接口1003可以包括显示屏（Display）、摄像头（Camera），可选用户接口1003还可以包括标准的有线接口、无线接口。

其中，网络接口1004可选的可以包括标准的有线接口、无线接口（如WI-FI接口）。

其中，处理器1001可以包括一个或者多个处理核心。处理器1001利用各种借口和线路连接整个服务器1000内的各个部分，通过运行或执行存储在存储器1005内的指令、程序、代码集或指令集，以及调用存储在存储器1005内的数据，执行服务器1000的各种功能和处理数据。可选的，处理器1001可以采用数字信号处理（Digital Signal Processing，DSP）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）、可编程逻辑阵列（Programmable Logic Array，PLA）中的至少一种硬件形式来实现。处理器1001可集成中央处理器（Central Processing Unit，CPU）、图像处理器（Graphics Processing Unit，GPU）和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器1001中，单独通过一块芯片进行实现。

其中，存储器1005可以包括随机存储器（Random Access Memory，RAM），也可以包括只读存储器（Read-Only Memory）。可选的，该存储器1005包括非瞬时性计算机可读介质（non-transitory computer-readable storage medium）。存储器1005可用于存储指令、程序、代码、代码集或指令集。存储器1005可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令（比如触控功能、声音播放功能、图像播放功能等）、用于实现上述各个方法实施例的指令等；存储数据区可存储上面各个方法实施例中涉及到的数据等。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图5所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及一种基于nodejs中间件对讲录音编解码方法的应用程序。

需要说明的是：上述实施例提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置和方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

在图5所示的电子设备1000中，用户接口1003主要用于为用户提供输入的接口，获取用户输入的数据；而处理器1001可以用于调用存储器1005中存储一种基于nodejs中间件对讲录音编解码方法的应用程序，当由一个或多个处理器执行时，使得电子设备执行如上述实施例中一个或多个所述的方法。

一种电子设备可读存储介质，其特征在于，所述电子设备可读存储介质存储有指令。当由一个或多个处理器执行时，使得电子设备执行如上述实施例中一个或多个所述的方法。

本领域的技术人员可以清楚地了解到本申请的技术方案可借助软件和/或硬件来实现。本说明书中的“单元”和“模块”是指能够独立完成或与其他部件配合完成特定功能的软件和/或硬件，其中硬件例如可以是现场可编程门阵列（Field－ProgrammaBLE GateArray，FPGA）、集成电路（Integrated Circuit，IC）等。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些服务接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器（Read-Only Memory， ROM）、随机存取存储器（Random Access Memory，RAM）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通进程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器（Read-Only Memory， ROM）、随机存取器（Random AccessMemory，RAM）、磁盘或光盘等。

以上所述者，仅为本公开的示例性实施例，不能以此限定本公开的范围。即但凡依本公开教导所作的等效变化与修饰，皆仍属本公开涵盖的范围内。本领域技术人员在考虑说明书及实践这里的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未记载的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的范围和精神由权利要求限定。

Claims (10)

1.一种基于nodejs中间件对讲录音编解码系统，其特征在于，所述系统包括：数据采集单元、数据处理单元和数据接收单元；所述数据采集单元在客户端上运行，所述数据处理单元和所述数据接收单元均在nodejs中间件上运行；

所述客户端与所述nodejs中间件建立socket连接，用于将音频数据发送至所述nodejs中间件；

所述nodejs中间件，用于将所述音频数据进行处理后持续发送至服务端。

2.根据权利要求1所述的基于nodejs中间件对讲录音编解码系统，其特征在于，所述数据采集单元由声音传感器组成，用于通过所述声音传感器将所述音频数据采集至所述客户端中。

3.根据权利要求1所述的基于nodejs中间件对讲录音编解码系统，其特征在于，所述数据处理单元包括合并压缩模块、分包解码压缩模块、封装排序模块以及发送模块，所述合并压缩模块、分包解码压缩模块、封装排序模块、发送模块依次进行数据连接；

所述合并压缩模块，用于将所述数据采集单元采集到的原始pcm音频数据进行偏移量计算，并将所述原始pcm音频数据进行合并压缩，得到合并压缩的音频数据；

所述分包解码压缩模块，用于将所述合并压缩的音频数据转换成指定采样率、采样数的音频数据；根据预置的分包算法将转换后的音频数据划分成pcm音频包，并根据opus编码算法将划分后的pcm音频包进一步转换成opus格式的音频包；

所述封装排序模块，用于将所述opus格式的音频包通过rtp进行封装，添加长度为8个字节的数据包头，得到封装完后的音频包，所述8个字节由4个字节的数据长度和4个字节的数据类型组成；将所述封装完后的音频包按照固定大小并通过分包机制进行分包排序，得到rtp格式的音频包；

所述发送模块，用于将所述rtp格式的音频包通过定时算法按照固定的时间间隔发送到服务端。

4.根据权利要求3所述的基于nodejs中间件对讲录音编解码系统，其特征在于，所述数据接收单元包括解码解压缩模块、数据拼接模块以及播放模块组成，所述解码解压缩模块、数据拼接模块和播放模块依次进行数据连接；

所述解码解压缩模块，用于将所述rtp格式的音频包去掉8个字节长度的数据包头和12字节长度的rtp头，以将所述rtp格式的音频包还原为所述opus格式的音频包，通过预置的opus解码算法将所述opus格式的音频包解压缩为pcm原始音频数据；

所述数据拼接模块，用于将所述pcm原始音频包根据音频包序号按照顺序依次进行合并，得到合并后的音频包；

所述播放模块，用于通过播放器将所述合并后的音频包通过客户端进行播放。

5.一种基于nodejs中间件对讲录音编解码的方法，其特征在于，应用于基于nodejs中间件对讲录音编解码系统，所述系统包括客户端、nodejs中间件以及服务端，所述客户端、nodejs中间件和服务端依次进行数据连接，所述方法包括：

所述客户端获取声音传感器的使用权限，并调用所述声音传感器进行音频流的采集，得到采集的原始pcm音频数据；

所述nodejs中间件通过数据处理单元将所述原始pcm音频数据合并与压缩，得到压缩的音频数据，并将所述压缩的音频数据进行进一步压缩封装排序，得到处理后的音频包，所述nodejs中间件将所述处理后的音频包发送至服务端；

所述服务端接收所述处理后的音频包，检验所述处理后的音频包是否符合规范，若符合规范则进行接收，若不符合规范则断开连接；

所述服务端将所述处理后的音频包发送至nodejs中间件进行接收时，所述数据接收单元接收处理后的音频包，所述数据处理单元将所述处理后的音频包进行解压还原，得到pcm音频包，并将所述pcm音频包进行排序合并，通过socket连接发送给客户端，并通过客户端的播放器进行播放。

6.根据权利要求5所述的基于nodejs中间件对讲录音编解码的方法，其特征在于，所述nodejs中间件通过所述数据处理单元将所述原始pcm音频数据合并与压缩，得到压缩的音频数据，包括：

所述nodejs中间件通过所述数据处理单元将所述原始pcm音频数据压缩转换为指定采样率以及采样位数的pcm音频数据，通过分包机制将所述pcm音频数据划分为固定大小的音频包，得到压缩的音频数据。

7.根据权利要求6所述的基于nodejs中间件对讲录音编解码的方法，其特征在于，所述将所述压缩的音频数据进行进一步压缩封装排序，得到处理后的音频包，包括：

所述nodejs中间件将所述压缩的音频数据通过opus编码压缩，并将所述pcm音频数据转换为opus格式的音频包，通过rtp将所述opus格式的音频包进行封装排序，得到处理后的音频包。

8.根据权利要求7所述的基于nodejs中间件对讲录音编解码的方法，其特征在于，所述通过rtp将所述opus格式的音频包进行封装排序，包括：

所述nodejs中间件将所述opus格式的音频包通过rtp添加长度为8个字节的数据包头，并按照固定大小通过分包机制进行分包封装排序，得到处理后的音频包，所述8个字节的数据包头由4个字节的数据长度和4个字节的数据类型组成。

9.根据权利要求5所述的基于nodejs中间件对讲录音编解码的方法，其特征在于，所述nodejs中间件将所述处理后的音频包发送至服务端，包括：

所述nodejs中间件将所述处理后的音频包进行分包，并按照预置的时间间隔持续将所述处理后的音频包发送至服务端。

10.根据权利要求5所述的一种基于nodejs中间件对讲录音编解码的方法，其特征在于，所述数据处理单元将所述处理后的音频包进行解压还原，得到pcm音频包，包括：

所述数据处理单元将所述处理后的音频包去掉包头和rtp头，还原为opus格式的音频包，根据opus解码算法将所述opus格式的音频包转换为指定采样率以及采样数的pcm音频包。

Images