CN114584481A - 一种音频信息采集方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种音频信息采集方法、装置、设备及存储介质。本申请实施例提供的技术方案通过在接收到管理端发送的调试开启请求时，确定调试开启请求所携带的第一用户信息和调试配置参数，并通知第一用户信息对应的第一用户端开启调试模式，第一用户端在调试模式下，将基于调试配置参数采集音频调试信息，在接收到管理端发送的调试关闭请求时，确定调试关闭请求所携带的第二用户信息，并通知第二用户信息对应的第二用户端关闭调试模式，第二用户端在关闭调试模式时，向文件服务器上传对应的音频调试信息，开发人员可根据音频调试信息对用户端进行分析处理并定位音频异常原因，音频信息采集流程简单高效。

Description

一种音频信息采集方法、装置、设备及存储介质

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种音频信息采集方法、装置、设备及存储介质。

背景技术

随着互联网技术的发展，越来越多的线上应用供用户选择使用，例如线上音频应用，用户可通过音频应用收听各种音频信息或者是进入语音房间进行交流沟通。但是在线上音频出现问题时，为了保证线上音频应用的正常使用，需要采集用户使用线上音频应用的过程中所产生的音频数据或日志数据，以供开发人员进行异常定位分析。

目前，线上音频问题的处理过程一般需要开发人员联系用户，由手动采集和上传音频数据或日志数据，开发人员再根据用户上传的音频数据或日志数据进行异常定位分析。但是在这样的流程下，用户的沟通成本和学习成本较高，导致音频数据或日志数据的采集效率较低。

发明内容

本申请实施例提供一种音频信息采集方法、装置、设备及存储介质，以解决现有技术中音频信息采集流程繁杂，用户的沟通成本和学习成本较高，导致音频数据或日志数据的采集效率较低的技术问题，提高音频信息采集效率。

在第一方面，本申请实施例提供了一种音频信息采集方法，包括：

接收管理端发送的调试开启请求，确定所述调试开启请求所携带的第一用户信息和调试配置参数；

基于所述第一用户信息通知对应的第一用户端开启调试模式，以使所述第一用户端在调试模式下基于所述调试配置参数采集音频调试信息；

接收所述管理端发送的调试关闭请求，确定所述调试关闭请求所携带的第二用户信息；

基于所述第二用户信息通知对应的第二用户端关闭调试模式，以使所述第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

在第二方面，本申请实施例提供了一种音频信息采集装置，包括开启响应模块、开启通知模块、关闭响应模块和关闭通知模块，其中：

所述开启响应模块，配置为接收管理端发送的调试开启请求，确定所述调试开启请求所携带的第一用户信息和调试配置参数；

所述开启通知模块，配置为基于所述第一用户信息通知对应的第一用户端开启调试模式，以使所述第一用户端在调试模式下基于所述调试配置参数采集音频调试信息；

所述关闭响应模块，配置为接收所述管理端发送的调试关闭请求，确定所述调试关闭请求所携带的第二用户信息；

所述关闭通知模块，配置为基于所述第二用户信息通知对应的第二用户端关闭调试模式，以使所述第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

在第三方面，本申请实施例提供了一种音频信息采集设备，包括：存储器以及一个或多个处理器；

所述存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的音频信息采集方法。

在第四方面，本申请实施例提供了一种存储计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面所述的音频信息采集方法。

本申请实施例通过在接收到管理端发送的调试开启请求时，确定调试开启请求所携带的第一用户信息和调试配置参数，并通知第一用户信息对应的第一用户端开启调试模式，第一用户端在调试模式下，将基于调试配置参数采集音频调试信息，在接收到管理端发送的调试关闭请求时，确定调试关闭请求所携带的第二用户信息，并通知第二用户信息对应的第二用户端关闭调试模式，第二用户端在关闭调试模式时，向文件服务器上传对应的音频调试信息，开发人员可根据音频调试信息对用户端进行分析处理并定位音频异常原因，音频信息采集流程简单高效，开发人员通过管理端通知用户端开启或关闭调试模式即可自动进行音频调试信息的采集与上传，不需要用户主动去采集及上传音频调试信息，有效降低用户的沟通成本和学习成本，提高音频数据或日志数据的采集效率。

附图说明

图1是本申请实施例提供的一种音频信息采集方法的流程图；

图2是本申请实施例提供的一种音频信息采集流程示意图；

图3是本申请实施例提供的另一种音频信息采集方法的流程图；

图4是本申请实施例提供的一种用户管理信息查询示意图；

图5是本申请实施例提供的一种音频信息采集装置的结构示意图；

图6是本申请实施例提供的一种音频信息采集设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时上述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。上述处理可以对应于方法、函数、规程、子例程、子程序等等。

图1给出了本申请实施例提供的一种音频信息采集方法的流程图，本申请实施例提供的音频信息采集方法可以由音频信息采集装置来执行，该音频信息采集装置可以通过硬件和/或软件的方式实现，并集成在音频信息采集设备(例如服务器)中。

下述以音频信息采集装置执行音频信息采集方法为例进行描述。参考图1，该音频信息采集方法包括：

S101：接收管理端发送的调试开启请求，确定调试开启请求所携带的第一用户信息和调试配置参数。

本实施例提供的用户端可以是手机、平板等智能设备，例如主播或观众所使用的智能设备，并可使用相关的音频功能(例如创建、加入语音房等)。其中，用户端包括第一用户端和第二用户端，其中第一用户端可以理解为需要开启调试模式以采集音频调试信息的用户端，第二用户端可理解为需要关闭调试模式以上传采集到的音频调试信息的用户端。可以理解的是，第一用户端和第二用户端可以是相同的用户端，也可以是不同的用户端。

在一个实施例中，开发人员在需要用户端开启调试模式采集音频调试信息时，可通过管理端设置所需要开启调试模式的第一用户端所对应的第一用户信息，以及指示需要采集的音频调试信息或相关配置信息的调试配置参数，根据第一用户信息和调试配置参数生成调试开启请求，并提交给音频信息采集装置。

示例性的，在接收到管理端发送的调试开启请求后，解析调试开启请求并确定调试开启请求所携带的第一用户信息和调试配置参数。其中，第一用户信息可以是用户标识(uid)、用户房间标识(sid)、用户账户标识等。

S102：基于第一用户信息通知对应的第一用户端开启调试模式，以使第一用户端在调试模式下基于调试配置参数采集音频调试信息。

示例性的，确定第一用户信息对应的第一用户端，并根据调试配置参数通知第一用户端开启调试模式。第一用户端在接收到调试模式开启通知后开启调试模式，并在调试模式下根据第一配置参数采集对应的音频调试信息，不需要用户主动收集音频调试信息。可选的，向用户端发送开启调试模式的调试模式开启通知和关闭调试模式的调试模式关闭通知，可以是通过Push(一种可以下发相关配置信息到指定用户客户端的特定方法)的方式向用户端发送。

在一个实施例中，第一用户端在开启调试模式并采集音频调试信息时，将采集到的音频调试信息保存到统一的存储路径上，后续在关闭调试模式时，将这个存储路径上的文件统一打包并上传，并将打包文件的URL地址埋点上报，方便开发人员获取打包文件。

在一个实施例中，音频调试信息包括音频转储数据(音频dump数据)和/或音频日志文件，第一用户端所采集的具体数据类型可在调试配置参数中进行设置。其中，音频转储数据可通过设定的音频软开工具包(MediaSDK)提供的音频转储功能(音频dump功能)实现。可选的，可在调试配置信息中设置文件过滤信息，第一用户端在收集音频调试信息时，可根据文件过滤信息对音频调试信息进行过滤，仅采集开发人员所关心的音频调试信息。例如，设置一个日志等级T(Trace)，在音频日志文件的文件等级达到日志等级T时，将音频日志文件保存到同一路径中，若音频日志文件的文件等级未达到日志等级T则忽略该音频日志文件，仅保存开发人员所关心的音频日志文件，精简音频日志文件，方便后续的音频问题分析，更容易对音频问题进行定位。

S103：接收管理端发送的调试关闭请求，确定调试关闭请求所携带的第二用户信息。

在一个实施例中，开发人员在需要用户端关闭调试模式以获取采集到的音频调试信息时，可通过管理端设置所需要关闭调试模式的第二用户端所对应的第二用户信息，根据第一用户信息和调试配置参数生成调试开启请求，并提交给音频信息采集装置。

示例性的，在接收到管理端发送的调试关闭请求后，解析调试关闭请求所携带的第二用户信息，该第二用户信息对应的第二用户端即为开发人员所需要关闭调试模式并获取采集到的音频调试信息的用户端。

S104：基于第二用户信息通知对应的第二用户端关闭调试模式，以使第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

示例性的，确定第二用户信息对应的第二用户端，并通知第二用户端关闭调试模式。第二用户端在接收到调试模式关闭通知后，关闭调试模式，并将在开启调试模式期间采集的音频调试信息打包上传到设定的文件服务器中。

进一步的，开发人员可根据所需要查询的音频调试信息所对应的用户信息，向文件服务器请求对应的音频调试信息，开发人员可利用音频调试信息对用户端在运行过程中使用音频相关功能所发生的异常，并定位问题位置。

如图2提供的一种音频信息采集流程示意图所示，开发人员需要用户端开始调试模式采集音频调试信息时，通过发送push消息的方式向音频信息采集装置发送调试开启请求，由音频信息采集装置向该客户端(此时该客户端作为第一客户端)发送调试模式开启通知，客户端通过配置好的Push通道通信工具(Push SDK)接收调试模式开启通知，并解析对应的调试配置参数并开启调试模式，通过MediaSDK采集音频转储数据和/或音频日志文件，并将采集到的音频转储数据和/或音频日志文件保存到统一存储路径。开发人员需要获取用户端采集到的音频调试信息时，通过发送push消息的方式向音频信息采集装置发送调试关闭请求，由音频信息采集装置向该客户端(此时该客户端作为第二客户端)发送调试模式关闭通知，客户端通过Push通道通信工具接收调试模式关闭通知，并关闭调试模式，并将统一存储路径中保存的音频转储数据和/或音频日志文件打包上传到文件服务器，并将打包文件的URL地址埋点上报，方面开发人员从文件服务器拉取音频转储数据和/或音频日志文件。

上述，通过在接收到管理端发送的调试开启请求时，确定调试开启请求所携带的第一用户信息和调试配置参数，并通知第一用户信息对应的第一用户端开启调试模式，第一用户端在调试模式下，将基于调试配置参数采集音频调试信息，在接收到管理端发送的调试关闭请求时，确定调试关闭请求所携带的第二用户信息，并通知第二用户信息对应的第二用户端关闭调试模式，第二用户端在关闭调试模式时，向文件服务器上传对应的音频调试信息，开发人员可根据音频调试信息对用户端进行分析处理并定位音频异常原因，音频信息采集流程简单高效，开发人员通过管理端通知用户端开启或关闭调试模式即可自动进行音频调试信息的采集与上传，不需要用户主动去采集及上传音频调试信息，有效降低用户的沟通成本和学习成本，提高音频数据或日志数据的采集效率。

在上述实施例的基础上，图3给出了本申请实施例提供的另一种音频信息采集方法的流程图，该音频信息采集方法是对上述音频信息采集方法的具体化，本方案在上述实施例提供的音频信息采集系统的基础上进一步设置。参考图3，该音频信息采集方法包括：

S201：接收管理端发送的用户查询请求，向管理端发送用户查询请求对应的用户管理信息，以供管理端基于用户管理信息确定发出调试开启请求。

在一个实施例中，开发人员在需要确定第一用户端所需要采集的数据类型以配置调试配置参数时，可基于第一用户端对应的用户管理信息进行确定。其中，用户管理信息可以包括第一用户端对应的反馈信息(例如用户在使用过程中出现异常时反馈的信息)、用户在设定时间段内的活动信息(例如用户所进入的房间信息、所执行的操作)、历史调试记录等。

开发人员可根据用户管理信息确定所需要采集的信息，并配置对应的调试配置参数。例如对于仅通过音频日志文件就能分析异常原因的情况，仅收集第一用户端生成的音频日志文件即可，或者是根据问题类型确定需要收集的核心音频日志文件，不需要收集音频转储数据或不相关音频日志文件，精简收集的数据量。或者对于仅通过音频日志文件无法准确分析异常原因的情况，则需要同时收集第一用户端生成的音频日志文件和音频转储数据，以保证准确分析异常原因。

进一步的，开发人员在根据用户管理信息确定需要收集的数据类型后，通过管理端配置对应的调试配置参数，根据对应的第一用户信息和调试配置参数发出调试开启请求。

在一个实施例中，如图4提供的一种用户管理信息查询示意图所示，可将每一次管理端发出的用户查询请求对应的用户管理信息保存在本地数据库中，用户端可通过向音频信息采集装置输入用户信息(例如uid、sid)发出用户查询请求，音频信息采集装置在接收到用户查询请求后，从本地数据库快速查询用户管理信息，若本地数据库未保存有对应用户的用户管理信息，则从设定的服务器中查询对应的用户管理信息，并保存在本地数据库中。其中本地数据库可采用Google提供的LevelDB数据库。其中，用户管理信息以json对象的格式保存在本地数据库中，同时，可将用户管理信息存储到应用全局状态中，方便对用户管理数据进行全局管理。

在一个实施例中，调试开启请求还可携带所需要上传的数据类型的标识信息，例如是否上传音频转储数据的第一标识信息以及是否上传音频日志文件的第二标识信息。第一用户端可根据标识信息确定需要上传到文件服务器的数据类型，向开发人员提供所需要的数据类型，精简上传的数据。

S202：接收管理端发送的调试开启请求，确定调试开启请求所携带的第一用户信息和调试配置参数。

S203：基于第一用户信息通知对应的第一用户端开启调试模式，以使第一用户端在调试模式下基于调试配置参数采集音频调试信息。

在一个实施例中，调试配置参数包括任务识别信息，该任务识别信息用于指示用户端在开启调试模式时，所需要监测的第一目标任务，并在执行第一目标任务过程中采集对应的音频调试信息。其中，任务识别信息由管理端在生成调试开启请求时，开发人员根据需要采集的时机或目标任务，将对应的任务表示信息配置在调试配置参数中。例如，用户反馈在进入语音房时音频播放出现异常，开发人员可将任务识别信息对应的第一目标任务设置为用户进入语音房(或进入设定房间号的语音房)。

基于此，在一个实施例中，在第一用户端在调试模式下基于调试配置参数采集音频调试信息时，具体包括：第一用户端开启调试模式，并在调试模式下监测调试配置参数中任务识别信息对应的第一目标任务。进一步的，第一用户端在确定执行第一目标任务时，采集执行目标任务对应的音频调试信息。

示例性的，第一用户端在开启调试模式时，在调试模式下检测是否有执行调试配置参数中任务识别信息对应的第一目标任务，并在检测到执行第一目标任务时，开始采集执行目标任务对应的音频调试信息。例如任务识别信息对应的第一目标任务设置为用户进入语音房，那么第一用户端在开启调试模式后，在检测到用户进入语音房时，MediaSDK开启dump音频功能采集音频转储数据，同时记录音频日志文件，并将音频转储数据和音频日志文件保存到统一的存储路径上。

S204：接收管理端发送的调试关闭请求，确定调试关闭请求所携带的第二用户信息。

S205：基于第二用户信息通知对应的第二用户端关闭调试模式，以使第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

在一个实施例中，第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息时，具体为：第二用户端关闭调试模式，并将采集得到的音频调试信息打包，并向文件服务器上传打包后的音频调试信息。

示例性的，用户端在采集音频调试信息时，是将采集到的音频调试信息保存到统一的存储路径上的，第二用户端在接收到调试关闭通知并关闭调试模式后，将统一存储路径上保存的音频调试信息打包并上传到文件服务器上。

S206：从文件服务器获取音频调试信息，基于设定的信息分析策略对音频调试信息进行分析处理得到调试分析信息。

示例性的，在第二用户端向文件服务器上传音频调试信息后，可从文件服务器获取音频调试信息，并基于设定的信息分析策略对音频调试信息进行分析处理得到调试分析信息。

例如，对于音频日志文件的分析处理，对应的信息分析策略可以是对音频调试信息进行聚类分析、计算平均值、计算局部最大值等，以方便快速的找出在音频调试信息中出现反映异常问题的地方，并可通过图表的方式显示调试分析信息，在绘制的图表中直观的显示音频调试信息中所反映的异常。对于音频转储数据的分析处理，对应的信息分析策略可以是生成音频转储数据对应的频谱图和波形图，并通过设定的音频分析算法(例如音频分类算法、深度学习、机器学习等)，通过参考各种音频指标的正常经验值范围，找出音频转储数据中的异常片段(例如出现高低频异常、电流声、卡顿声等片段)。

在一个可能的实施例中，可按照数据的生成过程将音频调试信息划分成不同的音频指标对应的数据类型，从文件服务器中获取音频调试信息后，按照音频调试信息对应的内容规范进行解析(例如通过正则匹配的方式进行解析)，得到不同数据类型的音频监控数据。在解析完成后，对各种数据类型的音频监控数据，以时间为横轴，各种音频指标类型为纵轴绘制图表，更直观的展示用户端在执行目标任务过程中各项音频指标的变化情况。例如，对于音频日志文件，根据日志的生成过程分成以下7类：在音频数据上行缓冲中生成的上行缓冲日志(jbuf_put日志)、在音频数据下行缓冲中生成的下行缓冲日志(jbuf_get日志)、网络传输缓冲日志(network_jitter日志)、音频状态统计日志(playback_plc日志)、请求与重发日志(req_and_resend日志)、音频加减速相关日志(scaling_delta日志)和语音包往返时间日志(rtt日志)。对于以上7类音频指标的数据类型，分别以时间为横轴，对应音频指标类型为纵轴绘制图表，开发人员可直观了解到不同数据指标的变化情况，更快地分析出现异常的环节。

可选的，在得到调试分析信息后，可根据用户信息将调试分析信息保存在本地数据库中，方便开发人员根据指定的用户信息获取对应的调试分析信息，快速定位音频异常原因。

在一个可能的实施例中，开发人员在需要获取音频调试信息进行异常定位分析时，可向管理端发出音频调试信息查询请求，以获取对应的音频调试信息。基于此，本方案还包括：接收管理端发送的音频调试信息查询请求，从文件服务器中获取音频调试信息查询请求对应的音频调试信息，并向管理端发送音频调试信息。示例性的，在接收到管理端发出的音频调试信息查询请求时，根据音频调试信息查询请求所对应的用户信息，从文件服务器中获取该用户信息所对应的音频调试信息并发送给管理端。

在一个可能的实施例中，开发人员在需要获取音频调试信息对应的调试分析信息时，可向管理端发出调试分析信息查询请求，以获取对应的调试分析信息。基于此，本方案还包括：接收管理端发送的调试分析信息查询请求，从文件服务器中获取调试分析信息查询请求对应的调试分析信息，并向管理端发送调试分析信息。示例性的，在接收到管理端发出的调试分析信息查询请求时，根据调试分析信息查询请求所对应的用户信息，从文件服务器中获取该用户信息所对应的调试分析信息并发送给管理端。

在一个实施例中，音频信息采集装置可基于Electron(一种使用JavaScript、Html构建跨平台桌面应用的框架，内部使用Chrome web内核，可以在桌面平台上运行web应用)跨平台解决方案，使用React(轻量级的前端网页UI开发框架)作为渲染层框架，以TypeScript(JavaScript的超集)为开发语言进行开发。音频信息采集装置上运行的应用按照Electron要求分为主进程和渲染进程两个进程，主进程用于管理页面窗口，提供native方法和网络请求接口，并管理数据库。渲染进程负责显示页面，提供UI层级的操作，开发人员可通过在管理端上访问web应用时间调试模式的开启和关闭请求，并获取对应的音频调试信息和调试分析信息。音频信息采集装置基于Electron框架，可统一处理用户信息查询和本地持久化、开关调试模式、处理日志和音频、智能分析日志音频等工作。通过这种跨平台一站式的音频信息采集方式，方便对线上用户的音频问题进行跟踪、定位，不需要跨越多个地方查询音频问题，也减少了开发人员与用户的沟通成本。

上述，通过在接收到管理端发送的调试开启请求时，确定调试开启请求所携带的第一用户信息和调试配置参数，并通知第一用户信息对应的第一用户端开启调试模式，第一用户端在调试模式下，将基于调试配置参数采集音频调试信息，在接收到管理端发送的调试关闭请求时，确定调试关闭请求所携带的第二用户信息，并通知第二用户信息对应的第二用户端关闭调试模式，第二用户端在关闭调试模式时，向文件服务器上传对应的音频调试信息，开发人员可根据音频调试信息对用户端进行分析处理并定位音频异常原因，音频信息采集流程简单高效，开发人员通过管理端通知用户端开启或关闭调试模式即可自动进行音频调试信息的采集与上传，不需要用户主动去采集及上传音频调试信息，有效降低用户的沟通成本和学习成本，提高音频数据或日志数据的采集效率。同时，第一用户端根据调试配置参数，在执行目标任务时才采集相关的音频调试信息，减少不必要数据的采集，并且在分析日志和音频过程中，通过简化日志并使用智能分析工具辅助定位问题，极大地提高了定位问题的效率。同时，根据不同的音频指标对音频调试信息进行分类，根据不同分类对应的音频分析算法进行分析处理得到不同音频指标下的调试分析信息，进一步提高音频异常定位分析的效率。

图5是本申请实施例提供的一种音频信息采集装置的结构示意图。参考图5，该音频信息采集装置包括开启响应模块51、开启通知模块52、关闭响应模块53和关闭通知模块54。

其中，开启响应模块51，配置为接收管理端发送的调试开启请求，确定调试开启请求所携带的第一用户信息和调试配置参数；开启通知模块52，配置为基于第一用户信息通知对应的第一用户端开启调试模式，以使第一用户端在调试模式下基于调试配置参数采集音频调试信息；关闭响应模块53，配置为接收管理端发送的调试关闭请求，确定调试关闭请求所携带的第二用户信息；关闭通知模块54，配置为基于第二用户信息通知对应的第二用户端关闭调试模式，以使第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

上述，通过在接收到管理端发送的调试开启请求时，确定调试开启请求所携带的第一用户信息和调试配置参数，并通知第一用户信息对应的第一用户端开启调试模式，第一用户端在调试模式下，将基于调试配置参数采集音频调试信息，在接收到管理端发送的调试关闭请求时，确定调试关闭请求所携带的第二用户信息，并通知第二用户信息对应的第二用户端关闭调试模式，第二用户端在关闭调试模式时，向文件服务器上传对应的音频调试信息，开发人员可根据音频调试信息对用户端进行分析处理并定位音频异常原因，音频信息采集流程简单高效，开发人员通过管理端通知用户端开启或关闭调试模式即可自动进行音频调试信息的采集与上传，不需要用户主动去采集及上传音频调试信息，有效降低用户的沟通成本和学习成本，提高音频数据或日志数据的采集效率。

本申请实施例还提供了一种音频信息采集设备，该音频信息采集设备可集成本申请实施例提供的音频信息采集装置。图6是本申请实施例提供的一种音频信息采集设备的结构示意图。参考图6，该音频信息采集设备包括：输入装置63、输出装置64、存储器62以及一个或多个处理器61；存储器62，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器61执行，使得一个或多个处理器61实现如上述实施例提供的音频信息采集方法。上述提供的音频信息采集装置、设备和计算机可用于执行上述任意实施例提供的音频信息采集方法，具备相应的功能和有益效果。

本申请实施例还提供一种存储计算机可执行指令的存储介质，计算机可执行指令在由计算机处理器执行时用于执行如上述实施例提供的音频信息采集方法。当然，本申请实施例所提供的一种存储计算机可执行指令的存储介质，其计算机可执行指令不限于如上提供的音频信息采集方法，还可以执行本申请任意实施例所提供的音频信息采集方法中的相关操作。上述实施例中提供的音频信息采集装置、设备及存储介质可执行本申请任意实施例所提供的音频信息采集方法，未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的音频信息采集方法。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里提供的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。

Claims (10)

1.一种音频信息采集方法，其特征在于，包括：

接收管理端发送的调试开启请求，确定所述调试开启请求所携带的第一用户信息和调试配置参数；

基于所述第一用户信息通知对应的第一用户端开启调试模式，以使所述第一用户端在调试模式下基于所述调试配置参数采集音频调试信息；

接收所述管理端发送的调试关闭请求，确定所述调试关闭请求所携带的第二用户信息；

基于所述第二用户信息通知对应的第二用户端关闭调试模式，以使所述第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

2.根据权利要求1所述的音频信息采集方法，其特征在于，所述调试配置参数包括任务识别信息，所述第一用户端在调试模式下基于所述调试配置参数采集音频调试信息，包括：

所述第一用户端开启调试模式，并在所述调试模式下监测所述调试配置参数中任务识别信息对应的第一目标任务；

所述第一用户端在确定执行所述第一目标任务时，采集执行所述目标任务对应的音频调试信息。

3.根据权利要求1所述的音频信息采集方法，其特征在于，所述第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息，包括：

所述第二用户端关闭调试模式，并将采集得到的音频调试信息打包；

向文件服务器上传打包后的所述音频调试信息。

4.根据权利要求1所述的音频信息采集方法，其特征在于，所述音频调试信息包括音频转储数据和/或音频日志文件。

5.根据权利要求1所述的音频信息采集方法，其特征在于，所述接收管理端发送的调试开启请求之前，还包括：

接收管理端发送的用户查询请求，向所述管理端发送所述用户查询请求对应的用户管理信息，以供所述管理端基于所述用户管理信息确定发出调试开启请求。

6.根据权利要求1所述的音频信息采集方法，其特征在于，所述基于所述第二用户信息通知对应的第二用户端关闭调试模式之后，还包括：

接收所述管理端发送的音频调试信息查询请求，从所述文件服务器中获取所述音频调试信息查询请求对应的音频调试信息，并向所述管理端发送所述音频调试信息。

7.根据权利要求1所述的音频信息采集方法，其特征在于，所述方法还包括：

从所述文件服务器获取所述音频调试信息，基于设定的信息分析策略对所述音频调试信息进行分析处理得到调试分析信息。

8.一种音频信息采集装置，其特征在于，包括开启响应模块、开启通知模块、关闭响应模块和关闭通知模块，其中：

所述开启响应模块，配置为接收管理端发送的调试开启请求，确定所述调试开启请求所携带的第一用户信息和调试配置参数；

所述开启通知模块，配置为基于所述第一用户信息通知对应的第一用户端开启调试模式，以使所述第一用户端在调试模式下基于所述调试配置参数采集音频调试信息；

所述关闭响应模块，配置为接收所述管理端发送的调试关闭请求，确定所述调试关闭请求所携带的第二用户信息；

所述关闭通知模块，配置为基于所述第二用户信息通知对应的第二用户端关闭调试模式，以使所述第二用户端关闭调试模式并向文件服务器上传对应的音频调试信息。

9.一种音频信息采集设备，其特征在于，包括：存储器以及一个或多个处理器；

所述存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7任一项所述的音频信息采集方法。

10.一种存储计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-7任一项所述的音频信息采集方法。

Images