音频处理系统的异常检测方法、日志记录方法及装置与流程

本申请涉及音频处理技术领域，尤其涉及音频处理系统的异常检测方法、日志记录方法及装置。

背景技术：

在直播场景、音视频聊天场景，都会涉及到音频处理系统，音频处理系统通常可以包括采集、混音、编码、传输、解码、播放等音频处理模块，音频从采集模块开始，经过各个模块处理，最终由播放模块播放。由于音频所经过的模块比较多，最终在播放时，若用户听不到声音或声音异常时，很难检测是音频处理系统中哪一级模块在处理过程中出现了问题，排查问题困难，效率低。

技术实现要素：

有鉴于此，为解决相关技术中的技术问题，本申请提供了音频处理系统的异常检测方法、日志记录方法及装置。

根据本申请实施例的第一方面，提供一种音频处理系统的异常检测方法，所述方法包括：

获取所述音频处理模块的日志；所述日志中记录有输入音频数据的输入音频参数和输出音频数据的输出音频参数，所述输入音频数据和输出音频数据根据预设时间和预设采样率从所述音频处理模块的输入端和输出端所采集得到；

基于所述输入音频参数和输出音频参数，判断所述音频处理模块是否异常。

根据本申请实施例的第二方面，提供一种音频处理系统日志记录方法，所述方法包括：

根据预设时间和预设采样率采集所述音频处理模块的输入音频数据和输出音频数据；

记录所述输入音频数据的输入音频参数和所述输出音频数据的输出音频参数，作为所述音频处理模块的日志。

根据本申请实施例的第三方面，提供一种音频处理系统的异常检测装置，所述装置包括：

获取模块，被配置为获取所述音频处理模块的日志；所述日志中记录有输入音频数据的输入音频参数和输出音频数据的输出音频参数，所述输入音频数据和输出音频数据根据预设时间和预设采样率从所述音频处理模块的输入端和输出端所采集得到；

判断模块，被配置为基于所述输入音频参数和输出音频参数，判断所述音频处理模块是否异常。

根据本申请的第四方面，提供一种音频处理系统的日志记录装置，所述装置包括：

采集模块，被配置为根据预设时间和预设采样率采集所述音频处理模块的输入音频数据和输出音频数据；

记录模块，被配置为记录所述输入音频数据的输入音频参数和所述输出音频数据的输出音频参数，作为所述音频处理模块的日志。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请中，根据预设时间和预设采样率采集音频处理模块的输入音频数据和输出音频数据，将输入音频数据的音频参数和输出音频数据的音频参数作为音频处理模块的日志，并根据日志记录内容检测音频处理系统是否异常。通过预设时间进行音频数据采样，可使得日志中无需记录太冗余的信息，当音频处理系统发生异常时，就可以通过日志中所记录的各音频处理模块对应的音频参数速检测音频处理模块是否异常，解决了音频处理系统发生异常时定位难、排查效率低的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

图1A为本申请所适用的一个直播场景的网络图。

图1B为本申请所适用的一个音频处理系统的网络图。

图2为本申请根据一示例性实施例示出的一种音频处理系统的日志记录方法的流程图。

图3为本申请根据一示例性实施例示出的一种对音频数据进行采样的示意图。

图4为本申请根据一示例性实施例示出的一种音频处理系统的异常检测方法的流程图。

图5为本申请根据一示例性实施例示出的一种音频处理系统的日志记录装置的框图。

图6为本申请根据一示例性实施例示出的一种音频处理系统的异常检测装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在常见的直播场景或音视频聊天等场景中，都会涉及到音频处理系统，本实施例以直播场景为例进行说明。如图1A所示，图1A是本申请所适用的一个直播场景的网络图，该直播场景可以包括有：主播客户端10、可与直播客户端10进行通信的直播服务器20及可与直播服务器20进行通信的观众客户端30a、30b。其中，上述主播客户端可以是主播使用的设备(如：电脑、手机等)，上述观众客户端可以是观众使用的设备(如：电脑、手机等)。其中，主播客户端可以包括一种或多种信号采集设备(如：摄像头、麦克风等)。在直播过程中，主播客户端10通过相应的信号采集设备采集到音/视频信号，并作为直播源数据上传到直播服务器20，并由直播服务器20将上传的直播源数据进行标准化，并编码为流媒体数据分发到一个或多个观众客户端上进行播放。

如图1B所示，图1B是本申请所适用的一个音频处理系统的网络图。音频数据从主播端开始，一般要经过采集、混音、编码、传输、解码和播放等六个音频处理模块的处理，最终在观众端播放。其中，采集模块、混音模块、编码模块配置在主播客户端，传输模块配置在服务端，解码模块、播放模块配置在观众客户端。可以理解，本实施例直播场景中所涉及的六个音频处理模块只为示例说明，在实际应用中，还可能涉及多种其他音频处理模块。由于音频处理系统中所涉及的音频处理模块众多，最终在播放时，若用户听不到声音或者声音出现异常时，难以排查，很难定位系统中哪个模块发生异常。

为此，本申请提出一种音频处理系统的日志记录方法和异常检测方法。可以根据预设时间和采样率采集音频处理模块的入音频数据和输出音频数据，并将输入音频数据的输入参数和输出音频数据的输出参数作为音频处理模块的日志；通过获取日志中的输入/输出音频参数，可以分析对应的音频处理模块是否异常，快速检测音频处理系统的异常。接下来对本申请进行详细说明。

如图2所示，图2是本申请根据一示例性实施例示出的一种音频处理系统的日志记录方法的流程图，该方法可应用于配置有音频处理模块的服务端设备或客户端设备中，用于对音频处理系统中的任一音频处理模块进行日志记录，所述方法包括以下步骤S201至S202：

在步骤S201中，根据预设时间和预设采样率采集所述音频处理模块的输入音频数据和输出音频数据。

在步骤S202中，记录所述输入音频数据的输入音频参数和所述输出音频数据的输出音频参数，作为所述音频处理模块的日志。

其中，采样率是指音频采集设备在一秒钟内对声音信号的采样次数，采样率越高，声音的还原越真实自然。采样率可以分为22.05kHz、44.1kHz、48kHz等多种等级，22.05kHz只能达到FM广播的声音品质，44.1kHz则是理论上的CD音质界限，48kHz则更加精确一些。作为一个例子，预设采样率可以是44.1kHz。

在实际应用中，预设时间可以灵活配置，例如可以根据采样率进行设定。如果采样率较高(比如采样率为192kHz)，由于所采集的音频数据量大，则可以设置较大的时间间隔，例如可以是每隔10秒采集一次音频数据；如果采样率较低(比如采样率为44.1kHz)，由于所采集的音频数据量小，则可以设置较小的时间间隔，例如可以是每隔2秒采集一次音频数据。在本实施例中，10秒、2秒都是经验值，实际应用中也可以是其他数值，比如5秒、8秒，1秒、3秒等，可以理解，若时间间隔短则所采集到的数据量大，日志中所记录的信息也较多，会增加实时记录和排查问题的困难；若时间间隔较大，则所采集到的数据量小，日志中所记录的信息也较少，会造成异常检测不精确的问题，因此在实际应用中可以根据需求灵活配置该预设时间。作为一个例子，对应于采样率44.1kHz，预设时间间隔可以为5秒。

音频数据的音频参数可以包括采样率、采样精度、比特率、通道数、数据长度、音量值以及前N个字节的数据等。本实施例中，获取音频参数的目的是为了后续进行异常分析，因此实际应用中，可以根据后续的异常分析需求，灵活配置所需的音频参数。在本申请实施例中，所述音频参数可以包括以下一种或多种：

数据长度、音量值以及前N个字节的数据，所述N为预设正整数。

数据长度指输入/输出音频数据的总字节数。通常一个音频处理模块输入音频数据的数据长度和输出音频数据的数据长度在正常传输过程中不会改变，当音频处理模块出现异常时则有可能造成数据丢失，导致音频处理模块输出音频数据的数据长度和输入音频数据的数据长度不一样。因此，可以根据输入音频数据的数据长度和输出音频数据的数据长度判断对应的音频处理模块是否异常，如果输出音频数据的数据长度和输入数据的音频长度不一样，则确定对应的音频处理模块异常。

音量值可以表示出某个音频数据是否无声，如果音量值小于预设值(比如-50分贝或-60分贝)就可以认为所采集的音频数据为一静音包。在直播或音视频聊天等场景，正常情况下音频数据应该都是有声音的，若音频数据无声，则可认为该音频数据异常。

前N个字节的数据可以用来判断输入/输出音频数据是否异常。N的具体数值可以灵活配置，一般取前8个字节的数据即可，也可以取前16或32个字节的数据，通常情况下，取前8个字节的数据可以获得足够的音频数据信息，以分析出输入/输出音频数据是否异常，取更多的数据也可以分析出数据是否异常，但可以理解的是，所取数据越多，分析模块异常的难度越大。

如图3所示，图3为本申请根据一实施例示出的一种对音频数据进行采样的示意图。在A时刻，预设时间到达，音频处理模块开始采集音频数据(假设采样率为44.1kHz)，时间段AB为1s，在1s内音频处理模块采集数据44100次数据，对应44100个采样点(即图3曲线上的圆点，其中，为了示例方便，图3中只示出了部分采样点)，本实施例中，可以只取前2个采样点所对应的数据，即前8个字节的数据进行分析。

通过上述方法可以记录音频处理系统中各音频处理模块的日志，日志中记录有音频处理模块输入音频数据的输入音频参数以及输出音频数据的输出音频参数。当系统出现异常时，就可以获取日志中的输入音频参数和输出音频参数，根据日志记录内容检测对应音频处理模块是否异常。下面对音频处理系统的异常检测方法进行详细介绍。

如图4所示，图4是本申请根据一示例性实施例示出的一种音频处理系统的异常检测方法的流程图，该方法可以应用在服务端设备或配置有至少一个音频处理模块的设备中，所述方法包括以下步骤S401至S402：

在步骤S401中，获取所述音频处理模块的日志；所述日志中记录有输入音频数据的输入音频参数和输出音频数据的输出音频参数，所述输入音频数据和输出音频数据根据预设时间和预设采样率从所述音频处理模块的输入端和输出端所采集得到。

在步骤S402中，基于所述输入音频参数和输出音频参数，判断所述音频处理模块是否异常。

音频处理系统有采集、混音、编码、传输、解码和播放等六个音频处理模块，在实际应用中，在不同的场景下，各音频处理模块可能配置在不同的设备，也有可能配置在同一设备中。

比如，在直播场景中，不同音频处理模块配置在不同设备，其中，采集模块、混音模块、编码模块配置在主播客户端设备，传输模块配置在服务端设备，解码模块、播放模块配置在观众客户端设备，因此在此类场景中，本实施例方法可以应用在服务端设备，也可以应用在配置有音频处理模块的设备中。例如，在直播场景中，可以应用在某一端设备(比如主播端、客户端或服务端)，用来检测本端设备中的音频处理模块是否异常；也可以应用在服务端，用来检测整个音频处理系统中各个音频处理模块(包括主播端和观众端设备中的音频处理模块)是否异常，这种情况下，获取每个音频处理模块的日志可以是音频处理模块主动上传至服务端，也可以是音频处理模块故障告警后提示用户手动上传至服务端。

还有一类音频处理设备，此类设备能够录音，并对录音进行去噪、音乐合成等处理，例如常见的安装有唱歌软件的设备、安装有录音处理软件的设备等，此类设备中的各模块都配置在同一设备。此种场景下，可以由该配置有音频处理系统的设备应用本实施例的异常检测方法，也可以是由与该音频处理系统对应的服务端应用本实施例的异常检测方法。

在本申请中，所述输入/输出音频参数包括以下一种或多种参数：

数据长度、音量值以及前N个字节的数据，所述N为预设正整数。其中，数据长度、音量值以及前N个字节的数据可参考图2实施例中的描述，在此不再赘述。

在本申请中，所述基于所述输入音频参数和输出音频参数，判断所述音频处理模块是否异常，包括：

如果输入音频数据的数据长度和输出音频数据的数据长度不同，则确定音频处理模块异常；或，

基于所述输入音频参数和输出音频参数判断所述输入音频数据和输出音频数据是否异常，通过判断结果确定音频处理模块是否异常。

在本实施例中，数据长度指输入/输出音频数据的总字节数。通常一个音频处理模块输入音频数据的数据长度和输出音频数据的数据长度在正常传输过程中不会改变，当音频处理模块出现异常时则有可能造成数据丢失，导致音频处理模块输出音频数据的数据长度和输入音频数据的数据长度不一样。因此，可以根据输入音频数据的数据长度和输出音频数据的数据长度判断对应的音频处理模块是否异常，如果输出音频数据的数据长度和输入数据的音频长度不一样，则确定对应的音频处理模块异常。

在另一个实施例中，如果音频数据异常，需要进一步判断是音频数据本身的问题还是音频处理系统中对应的音频处理模块异常。本实施例可通过如下方式判断：

如果输出音频数据正常，则确定对应音频处理模块正常；

如果输出音频数据异常，且输入音频数据正常，则确定对应音频处理模块异常。

通过以上方式可以判断音频处理系统某一模块是否故障，判断时一般从最后一级模块开始逐个往上排查，也可以几个模块同时排查，判断音频数据在哪一模块出了什么问题。

在本实施例中，需要判断音频数据是否异常。由于日志中记录有音频处理模块的输出音频数据和输出音频数据的音频参数，因此基于音频参数可以判断音频数据是否异常，比如音频数据无效、出现卡顿或噪声点以及静音等，本实施例中，判断输入音频数据或输出音频数据是否异常，可以通过以下一种或多种方式：

如果所述输入/输出音频数据的前N个字节的数据全部是0，则确定输入/输出音频数据无效。

如果所述输入/输出音频数据的前N个字节的数据都相同，则确定输入/输出音频数据异常。

如果所述输入/输出音频数据的音量值小于预设值，则确定所述输入/输出音频数据异常。

本实施例中，正常情况下，音频数据中，前N个字节的数据不会是全0，即使在静默状态下，也不会是全0。因此，如果上述字节全部是0，则可以确定为无效的音频数据，即音频数据异常。

在本实施例中，正常情况下，音频数据中，前N个字节的数据不会重复，如果字节的值重复相同，则可以确定声音出现卡顿或者噪声点，即音频数据异常。

音量值能表示出该声音数据是否无声，如果音量值太小，比如小于-50分贝或-60分贝，则可以确定该音频数据是一个静音包，即音频数据异常。

下面是日志中某音频处理模块输出音频数据的输出音频参数(音频采样率为44.1kHz，预设时间间隔为5秒，记录音频数据的数据长度、对应的音量值和前8个字节的数据)，该日志涉及4条记录：

2016-5-25 15:8:40 494ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 5A 03 76 90 0E 64 87 00...volume＝-12dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

2016-5-25 15:8:45 784ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 78 87 23 41 65A3 59 92...volume＝-20dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

2016-5-25 15:8:50 760ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 23 45 84 45 23 12 E6 62...volume＝-9dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

2016-5-25 15:8:55 241ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 16 03 18 09 98 67 E2 02...volume＝-33dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

其中，2016-5-25 15:8:40表示记录日志的时间；

Loginex.dll表示音频数据对应的音频处理模块；

3528bytes表示音频数据的数据长度为3528bytes；

5A 03 76 90 0E 64 87 00表示音频数据的前8个字节的数据；

volume＝-12dB表示音频数据的音量值为-12dB。

从上述日志中可以看出，前8个字节的数据不满足音频数据异常的条件(前8个字节的数据全部是0，或前8个字节的数据都相同或音量值小于预设值)，因此此段时间内输出音频数据正常，从而可以得知对应的音频处理模块正常。

下面是日志中某音频处理模块输出音频数据的输出音频参数(音频采样率为44.1kHz，预设时间间隔为5秒，记录前音频数据的长度、对应的音量值和前8个字节)：

2016-5-25 16:8:40 494ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 5A 03 76 90 0E 64 87 00...volume＝-12dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

2016-5-25 16:8:45 784ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 5A 03 76 90 0E 64 87 00...volume＝-20dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

2016-5-25 16:8:50 760ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 5A 03 76 90 0E 64 87 00...volume＝-9dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

2016-5-25 16:8:55 241ms Final loginex.dll YYDirector"Feed audiosdk 3528bytes 5A 03 76 90 0E 64 87 00...volume＝-33dB"ChannelAudio::sendAudioData ChannelAudio.cpp line:184

从上述日志中可以看出，前8个字节的数据，因此可以判断音频数异常(音频数据在这段时间内出现卡顿或噪声点)，如果此时再获取此音频数据对应的输入音频参数，如果确定输入音频数据正常，则可以确定此音频处理模块异常。

与前述音频处理系统异常检测方法的实施例相对应，本申请还提供了音频处理系统的日志记录装置和异常检测装置的实施例。

请参考图5，图5为本申请根据一示例性实施例示出的一种音频处理系统的日志记录装置的框图，所述装置500包括：采集模块501、记录模块502。

其中，采集模块501，被配置为根据预设时间和预设采样率采集所述音频处理模块的输入音频数据和输出音频数据。

记录模块502，被配置为记录所述输入音频数据的输入音频参数和所述输出音频数据的输出音频参数，作为所述音频处理模块的日志。

在一个可选的实现方式中，所述音频参数包括以下一种或多种：

数据长度、音量值以及前N个字节的数据，所述N为预设正整数。

如图6所示，图6为本申请根据一示例性实施例示出的一种音频处理系统的异常检测装置的框图，所述装置包括：获取模块601，判断模块602。

其中，获取模块601，被配置为获取所述音频处理模块的日志；所述日志中记录有输入音频数据的输入音频参数和输出音频数据的输出音频参数，所述输入音频数据和输出音频数据根据预设时间和预设采样率从所述音频处理模块的输入端和输出端所采集得到。

判断模块602，被配置为基于所述输入音频参数和输出音频参数，判断所述音频处理模块是否异常。

在一个可选的实现方式中，所述音频参数包括以下一种或多种：

数据长度、音量值以及前N个字节的数据，所述N为预设正整数。

在一个可选的实现方式中，所述判断模块具体用于：

如果输入音频数据的数据长度和输出音频数据的数据长度不同，则确定音频处理模块异常；或，

基于所述输入音频参数和输出音频参数判断所述输入音频数据和输出音频数据是否异常，通过判断结果确定音频处理模块是否异常。

在一个可选的实现方式中，所述判断模块具体用于：

如果输出音频数据正常，则确定对应的音频处理模块正常；

如果输入音频数据正常，且输出音频数据异常，则确定对应音频处理模块异常。

在一个可选的实现方式中，所述判断模块具体用于：通过如下一种或多种方式确定输入/输出音频数据异常，否则确定输入/输出音频数据正常：

如果所述输入/输出音频数据的前N个字节的数据全部是0，则确定输入/输出音频数据异常；

如果所述输入/输出音频数据的前N个字节的数据都相同，则确定输入/输出音频数据异常；

如果所述输入/输出音频数据的音量值小于预设值，则确定所述输入/输出音频数据异常。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。