一种音频播放监控方法及相关设备与流程

本申请涉及电子技术领域，尤其涉及一种音频播放监控方法及相关设备。

背景技术：

在音频的飞速发展下，用户对音频相关需求越来越大，评判、监控以及解决音频相关问题变得越来越复杂。例如，播放卡顿、开发难定位、本地难复现、无法评估外网的真实情况等等。由于没有办法对出现问题的地方进行监控，因此无法评估卡顿状态，导致解决问题的效率低下。

技术实现要素：

本申请实施例提供一种音频播放监控方法及相关设备。可以提高音频播放监控的准确性，进而提高解决音频问题的效率。

第一方面，本申请实施例提供了一种音频播放监控方法，包括：

使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，所述数据结构体用于记录所述当前播放音频的数据的读写地址；

获取所述数据结构体中所记录的所述当前播放音频的数据的写入位置处的第一偏移地址、以及所述当前播放音频的数据的读取位置处的第二偏移地址；

根据所述第一偏移地址确定写入的所述当前播放音频的数据的第一数据大小、以及根据所述第二偏移地址确定读取的所述当前播放音频的数据的第二数据大小；

根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的播放状态

其中，所述根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的播放状态包括：

当所述第一数据大小小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为卡顿状态。

其中，所述确定所述当前播放音频的数据的所述播放状态为卡顿状态之后，还包括：

获取上一次停止写入所述当前播放音频的数据的第一时间点、以及当前开始写入所述当前播放音频的数据的第二时间点；

根据所述第二时间点以及所述第一时间点，确定停止写入所述当前播放音频的数据的第一时长；

确定在所述第一时间点到所述第二时间点的时间段内读取共享缓冲区中的所述当前播放音频的数据所需的第二时长；

将所述第一时长减去所述第二时长，计算得到差值作为卡顿时长。

其中，所述方法还包括：

获取所述数据结构体中所记录的共享缓冲区的空间大小；

根据所述共享缓冲区的所述空间大小，在所述共享缓冲区内循环写入所述当前播放音频的数据以及读取所述当前播放音频的数据。

其中，所述根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的播放状态之后，还包括：

获取在所述当前播放音频的数据发生卡顿时的操作记录；

根据所述操作记录，确定引起所述当前播放音频的数据发生卡顿的操作事件。

其中，所述根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的播放状态之后，还包括：

显示提示信息，所述提示信息用于提醒用户所述当前播放音频的数据的所述播放状态。

第二方面，本申请实施例提供了一种音频播放监控装置，包括：

监控模块，用于使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，所述数据结构体用于记录所述当前播放音频的数据的读写地址；

获取模块，用于获取所述数据结构体中所记录的所述当前播放音频的数据的写入位置处的第一偏移地址、以及所述当前播放音频的数据的读取位置处的第二偏移地址；

处理模块，用于根据所述第一偏移地址确定写入的所述当前播放音频的数据的第一数据大小、以及根据所述第二偏移地址确定读取的所述当前播放音频的数据的第二数据大小；根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的播放状态。

其中，所述处理模块，还用于当所述第一数据大小小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为卡顿状态。

其中，所述获取模块，还用于获取上一次停止写入所述当前播放音频的数据的第一时间点、以及当前开始写入所述当前播放音频的数据的第二时间点；所述处理模块，还用于根据所述第二时间点以及所述第一时间点，确定停止写入所述当前播放音频的数据的第一时长；确定在所述第一时间点到所述第二时间点的时间段内读取共享缓冲区中的所述当前播放音频的数据所需的第二时长；将所述第一时长减去所述第二时长，计算得到差值作为卡顿时长。

其中，所述获取模块，还用于获取所述数据结构体中所记录的共享缓冲区的空间大小；所述处理模块，还用于根据所述共享缓冲区的所述空间大小，在所述共享缓冲区内循环写入所述当前播放音频的数据以及读取所述当前播放音频的数据。

其中，所述获取模块，还用于获取在所述当前播放音频的数据发生卡顿时的操作记录；所述处理模块，还用于根据所述操作记录，确定引起所述当前播放音频的数据发生卡顿的操作事件。

其中，所述装置还包括：

显示模块，还用于显示提示信息，所述提示信息用于提醒用户所述当前播放音频的数据的所述播放状态。

第三方面，本申请实施例提供了一种音频播放监控设备，包括：处理器、存储器和通信总线，其中，通信总线用于实现处理器和存储器之间连接通信，处理器执行存储器中存储的程序用于实现上述第一方面提供的一种音频播放监控方法中的步骤。

在一个可能的设计中，本申请实施例提供的音频播放监控设备可以包含用于执行上述方法设计中音频播放监控装置的行为相对应的模块。模块可以是软件和/或是硬件。

又一方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

又一方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面的方法。

实施本申请实施例，首先使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，数据结构体用于记录当前播放音频的数据的读写地址；然后获取数据结构体中所记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址；其次根据第一偏移地址确定写入的当前播放音频的数据的第一数据大小、以及根据第二偏移地址确定读取的当前播放音频的数据的第二数据大小；最后根据第一数据大小以及第二数据大小，确定当前播放音频的数据的播放状态。通过使用监控拦截函数对当前播放情况进行监控，从而可以对当前播放状况进行准确判断，以便及时上报相关信息，从而提高解决音频问题的效率。

附图说明

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

图1是本申请实施例提出的一种音频播放监控方法的流程示意图；

图2是本申请实施例提供的一种当前播放音频的数据播放的流程示意图；

图3(a)是本申请实施例提供的一种共享缓冲区的示意图；

图3(b)是本申请实施例提供的另一种共享缓冲区的示意图；

图3(c)是本申请实施例提供的又一种共享缓冲区的示意图；

图3(d)是本申请实施例提供的又一种共享缓冲区的示意图；

图3(e)是本申请实施例提供的又一种共享缓冲区的示意图；

图4是本申请实施例提出的又一种音频播放监控方法的流程示意图；

图5是本申请实施例提供的一种音频播放监控装置的结构示意图；

图6是本申请实施例提出的一种音频播放监控设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参考图1，图1是本申请实施例提供的一种音频播放监控方法的流程示意图。如图所示，本申请实施例中的步骤包括：

s101，使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，所述数据结构体用于记录所述当前播放音频的数据的读写地址。

如图2所示，对于在线音乐或本地音乐，当前播放音频的数据先写入sd卡，然后播放器对当前播放音频的数据进行解码(decode)得到脉冲编码调制(pulsecodemodulation，pcm)，然后加音效。加音效完成后调用系统(audiotrack)的方法write统一写入，然后交给系统的(audioflinger)来处理，而维护和管理audiotrack和audioflinger是数据结构体audio_track_cblk_t。其中，audio_track_cblk_t是audiotrack和audioflinger共享的数据结构体，audiotrack向audio_track_cblk_t中写入当前播放音频的数据，audioflinger从audio_track_cblk_t中读取当前播放音频的数据。在本申请实施例中，可以将监控拦截函数(如hook函数)加入到当前播放音频的数据的播放进程中，通过hook函数对数据结构体audio_track_cblk_t进行监控，以便获取当前播放的当前播放音频的数据的读写地址。

其中，audio_track_cblk_t中包括3个变量：server–audiotrack记录当前的写入位置处的偏移地址；user–audioflinger记录当前的读取位置处的偏移地址；framecount--audio_track_cblk_t还定义了共享缓冲区sharebuffer的大小，以当前播放音频的数据的帧为单位。

需要说明的是，hook(钩子)是android平台的一种消息处理机制，hook机制允许应用程序截获处理android消息或特定事件，钩子实际上是一个处理消息的程序段，通过系统调用，将hook函数挂入系统，在加载并播放当前播放音频的数据之前，通过hook函数首先捕获该当前播放音频的数据的相关信息，然后加工处理该当前播放音频的数据，也可以不作处理而继续传递该当前播放音频的数据，还可以强制结束该当前播放音频的数据的传递。而本申请实施例是在audiotrack调用方法write时进行拦截，获取当前播放音频的数据的读写情况来判断是否出现卡顿状况。

s102，获取所述数据结构体中所记录的所述当前播放音频的数据的写入位置处的第一偏移地址、以及所述当前播放音频的数据的读取位置处的第二偏移地址。

具体实现中，在当前播放音频的数据播放过程中，将当前播放音频的数据的当前写入位置处的偏移地址、以及当前读取位置处的偏移地址记录到数据结构体中。当执行到hook函数时，在audiotrack调用方法write时进行拦截，从数据结构体中获取记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址。

s103，根据所述第一偏移地址确定写入的所述当前播放音频的数据的第一数据大小(server值)、以及根据所述第二偏移地址确定读取的所述当前播放音频的数据的第二数据大小(user值)。

s104，根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的所述播放状态。

具体实现中，当所述第一数据大小小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为卡顿状态。当所述第一数据大小不小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为流畅状态，可以对当前播放音频的数据进行正常播放。

可选的，可以显示提示信息，所述提示信息用于提醒用户所述当前播放音频的数据的所述播放状态。

可选的，audio_track_cblk_t还定义了共享缓冲区sharebuffer的大小。可以获取所述数据结构体中所记录的共享缓冲区的空间大小；根据所述共享缓冲区的所述空间大小，在所述共享缓冲区内循环写入所述当前播放音频的数据以及读取所述当前播放音频的数据。

例如，如图3(a)所示，定义了一个七个元素空间的圆形共享缓冲区，其中，底部的单线与箭头表示“头尾相接”形成一个圆形地址空间。如图3(b)所示，首先1被写入共享缓冲区，再写入2个元素2和3。如图3(c)所示，如果读取最先写入的两个元素，那么共享缓冲区只剩下3。如图3(d)所示，继续写入当前播放音频的数据，将共享缓冲区的剩余空间填满。如图3(e)所示，如果共享缓冲区已经填满，需要写入新的当前播放音频的数据，则写入2个新的当前播放音频的数据a&b，覆盖掉最先写入的3和4。如此循环往复。

在本申请实施例中，首先使用监控拦截函数对当前播放音频的数据结构体进行监控，然后获取数据结构体中所记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址；最后根据第一偏移地址以及第二偏移地址，确定当前播放音频的数据的播放状态。通过使用监控拦截函数对当前播放情况进行监控，获取底层数据audio_track_cblk_t中的server值和user值，从而可以对当前播放状况进行准确判断。

请参考图4，图4是本申请实施例提供的一种音频播放监控方法的流程示意图。如图所示，本申请实施例中的步骤包括：

s401，使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，所述数据结构体用于记录所述当前播放音频的数据的读写地址。

如图2所示，对于在线音乐或本地音乐，当前播放音频的数据先写入sd卡，然后播放器对当前播放音频的数据进行解码(decode)得到脉冲编码调制(pulsecodemodulation，pcm)，然后加音效。加完音效后调用系统(audiotrack)的方法write统一写入，然后交给系统的(audioflinger)来处理，而维护和管理audiotrack和audioflinger是数据结构体audio_track_cblk_t。其中，audio_track_cblk_t是audiotrack和audioflinger共享的数据结构体，audiotrack向audio_track_cblk_t中写入当前播放音频的数据，audioflinger从audio_track_cblk_t中读取当前播放音频的数据。可以将监控拦截函数(如hook函数)加入到当前播放音频的数据的播放进程中，通过hook函数对数据结构体audio_track_cblk_t进行监控，以便获取当前播放的当前播放音频的数据的读写地址。

其中，audio_track_cblk_t中包括3个变量：server–audiotrack记录当前的写入位置处的偏移地址；user–audioflinger记录当前的读取位置处的偏移地址；framecount--audio_track_cblk_t还定义了共享缓冲区sharebuffer的大小，以当前播放音频的数据的帧为单位。

需要说明的是，hook(钩子)是android平台的一种消息处理机制，hook机制允许应用程序截获处理android消息或特定事件，钩子实际上是一个处理消息的程序段，通过系统调用，将hook函数挂入系统，在加载并播放当前播放音频的数据之前，通过hook函数首先捕获该当前播放音频的数据的相关信息，然后加工处理该当前播放音频的数据，也可以不作处理而继续传递该当前播放音频的数据，还可以强制结束该当前播放音频的数据的传递。而本申请实施例是在audiotrack调用方法write时进行拦截，获取当前播放音频的数据的读写情况来判断是否出现卡顿状况。

s402，获取所述数据结构体中所记录的所述当前播放音频的数据的写入位置处的第一偏移地址、以及所述当前播放音频的数据的读取位置处的第二偏移地址。

具体实现中，在当前播放音频的数据播放过程中，将当前播放音频的数据的当前写入位置处的偏移地址、以及当前读取位置处的偏移地址记录到数据结构体中。当执行到hook函数时，在audiotrack调用方法write时进行拦截，从数据结构体中获取记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址。

s403，根据所述第一偏移地址以及所述第二偏移地址，确定所述当前播放音频的数据的播放状态。

具体实现中，可以首先根据所述第一偏移地址确定写入的所述当前播放音频的数据的第一数据大小(server值)、以及根据所述第二偏移地址确定读取的所述当前播放音频的数据的第二数据大小(user值)；然后根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的所述播放状态。

进一步的，当所述第一数据大小小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为卡顿状态。当所述第一数据大小不小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为流畅状态，可以对当前播放音频的数据进行正常播放。

可选的，audio_track_cblk_t还定义了共享缓冲区sharebuffer的大小。可以获取所述数据结构体中所记录的共享缓冲区的空间大小；根据所述共享缓冲区的所述空间大小，在共享缓冲区内循环写入所述当前播放音频的数据以及读取所述当前播放音频的数据。

例如，如图3(a)所示，定义了一个七个元素空间的圆形共享缓冲区，其中，底部的单线与箭头表示“头尾相接”形成一个圆形地址空间。如图3(b)所示，首先1被写入共享缓冲区，再写入2个元素2和3。如图3(c)所示，如果读取最先写入的两个元素，那么共享缓冲区只剩下3。如图3(d)所示，继续写入当前播放音频的数据，将共享缓冲区的剩余空间填满。如图3(e)所示，如果共享缓冲区已经填满，需要写入新的当前播放音频的数据，则写入2个新的当前播放音频的数据a&b，覆盖掉最先写入的3和4。如此循环往复。

s404，若确定所述当前播放音频的数据的所述播放状态为卡顿状态，则获取在所述当前播放音频的数据发生卡顿时的操作记录。

具体实现中，每次进入到一个界面或者进行点击操作事件，都可以记录到一个文件中。例如，在进入操作界面a时，将此操作事件记录到该文件中，当用户在操作界面a上进行点击操作时，将此操作事件也记录到该文件中；在进入操作界面b时，将此操作事件也记录到该文件中，当用户在操作界面b上进行点击操作时，将此操作事件也记录到该文件中，依次按照相同的方法将进入其他操作界面并在其他操作界面进行操作的事件记录到该文件中。当确定当前播放音频的数据播放过程中出现卡顿时，可以从该文件中获取在当前播放音频的数据发生卡顿时的操作记录。

s405，根据所述操作记录，确定引起所述当前播放音频的数据发生卡顿的操作事件。

具体实现中，可以根据操作记录，复现发生卡顿时的操作过程，确定引起当前播放音频的数据发生卡顿的操作事件，从而查找卡顿原因。

可选的，可以获取上一次停止写入所述当前播放音频的数据的第一时间点、以及当前开始写入所述当前播放音频的数据的第二时间点；根据所述第二时间点以及所述第一时间点，确定停止写入所述当前播放音频的数据的第一时长；确定在所述第一时间点到所述第二时间点的时间段内读取共享缓冲区中的所述当前播放音频的数据所需的第二时长；将所述第一时长减去所述第二时长，计算得到差值作为卡顿时长。

例如，假设共享缓冲区中上次剩余的当前播放音频的数据可以播放100ms，并记录上次写入当前播放音频的数据时间戳为t1，当前写入当前播放音频的数据时记录时间戳t2。在t2-t1这段时间内，没有向共享缓冲区写入当前播放音频的数据。共享缓冲区只能播放100ms，假设t2-t1为1000ms，则下一次写入数据需要等待1000ms，因此卡顿时长为900ms。

可选的，可以向服务器发送卡顿的相关信息，服务器接收到相关信息之后，可以根据相关信息确定解决方案，并向用户设备返回解决方案，以便用户设备可以及时解决出现卡顿的问题。其中，相关信息可以包括出现卡顿时的操作记录以及卡顿时长等等。

在本申请实施例中，首先使用监控拦截函数对数据结构体进行监控，然后获取数据结构体中所记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址；最后根据第一偏移地址以及第二偏移地址，确定当前播放音频的数据的播放状态。通过使用监控拦截函数对当前播放情况进行监控，从而可以对当前播放状况进行准确判断，以便及时上报相关信息，从而提高解决问题的效率。

请参考图5，图5是本申请实施例提供的一种音频播放监控装置的结构示意图。如图所示，本申请实施例中的装置包括：

监控模块501，用于使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，所述数据结构体用于记录所述当前播放音频的数据的读写地址。

如图2所示，对于在线音乐或本地音乐，当前播放音频的数据先写入sd卡，然后播放器对当前播放音频的数据进行解码(decode)得到脉冲编码调制(pulsecodemodulation，pcm)，然后加音效。加完音效后调用系统(audiotrack)的方法write统一写入，然后交给系统的(audioflinger)来处理，而维护和管理audiotrack和audioflinger是数据结构体audio_track_cblk_t。其中，audio_track_cblk_t是audiotrack和audioflinger共享的数据结构体，audiotrack向audio_track_cblk_t中写入当前播放音频的数据，audioflinger从audio_track_cblk_t中读取当前播放音频的数据。可以将监控拦截函数(如hook函数)加入到当前播放音频的数据的播放进程中，通过hook函数对数据结构体audio_track_cblk_t进行监控，以便获取当前播放的当前播放音频的数据的读写地址。

其中，audio_track_cblk_t中包括3个变量：server–audiotrack记录当前的写入位置处的偏移地址；user–audioflinger记录当前的读取位置处的偏移地址；framecount--audio_track_cblk_t还定义了共享缓冲区sharebuffer的大小，以当前播放音频的数据的帧为单位。

需要说明的是，hook(钩子)是android平台的一种消息处理机制，hook机制允许应用程序截获处理android消息或特定事件，钩子实际上是一个处理消息的程序段，通过系统调用，将hook函数挂入系统，在加载并播放当前播放音频的数据之前，通过hook函数首先捕获该当前播放音频的数据的相关信息，然后加工处理该当前播放音频的数据，也可以不作处理而继续传递该当前播放音频的数据，还可以强制结束该当前播放音频的数据的传递。而本申请实施例是在audiotrack调用方法write时进行拦截，获取当前播放音频的数据的读写情况来判断是否出现卡顿状况。

获取模块502，用于获取所述数据结构体中所记录的所述当前播放音频的数据的写入位置处的第一偏移地址、以及所述当前播放音频的数据的读取位置处的第二偏移地址。

具体实现中，在当前播放音频的数据播放过程中，将当前播放音频的数据的当前写入位置处的偏移地址、以及当前读取位置处的偏移地址记录到数据结构体中。当执行到hook函数时，在audiotrack调用方法write时进行拦截，从数据结构体中获取记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址。

处理模块503，用于根据所述第一偏移地址确定写入的所述当前播放音频的数据的第一数据大小(server值)、以及根据所述第二偏移地址确定读取的所述当前播放音频的数据的第二数据大小(user值)；然后根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的所述播放状态。

具体实现中，当所述第一数据大小小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为卡顿状态。当所述第一数据大小不小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为流畅状态，可以对当前播放音频的数据进行正常播放。

可选的，显示模块404，用于显示提示信息，所述提示信息用于提醒用户所述当前播放音频的数据的所述播放状态。

可选的，audio_track_cblk_t还定义了共享缓冲区sharebuffer的大小。可以获取所述数据结构体中所记录的共享缓冲区的空间大小；根据所述共享缓冲区的所述空间大小，在共享缓冲区内循环写入所述当前播放音频的数据以及读取所述当前播放音频的数据。

例如，如图3(a)所示，定义了一个七个元素空间的圆形共享缓冲区，其中，底部的单线与箭头表示“头尾相接”形成一个圆形地址空间。如图3(b)所示，首先1被写入共享缓冲区，再写入2个元素2和3。如图3(c)所示，如果读取最先写入的两个元素，那么共享缓冲区只剩下3。如图3(d)所示，继续写入当前播放音频的数据，将共享缓冲区的剩余空间填满。如图3(e)所示，如果共享缓冲区已经填满，需要写入新的当前播放音频的数据，则写入2个新的当前播放音频的数据a&b，覆盖掉最先写入的3和4。如此循环往复。

可选的，若确定所述当前播放音频的数据的所述播放状态为卡顿状态，则获取在所述当前播放音频的数据发生卡顿时的操作记录。根据所述操作记录，确定引起所述当前播放音频的数据发生卡顿的操作事件。

具体实现中，每次进入到一个界面或者进行点击操作事件，都可以记录到一个文件中。例如，在进入操作界面a时，将此操作事件记录到该文件中，当用户在操作界面a上进行点击操作时，将此操作事件也记录到该文件中；在进入操作界面b时，将此操作事件也记录到该文件中，当用户在操作界面b上进行点击操作时，将此操作事件也记录到该文件中，依次按照相同的方法将进入其他操作界面并在其他操作界面进行操作的事件记录到该文件中。当确定当前播放音频的数据播放过程中出现卡顿时，可以从该文件中获取在当前播放音频的数据发生卡顿时的操作记录。可以根据操作记录，复现发生卡顿时的操作过程，确定引起当前播放音频的数据发生卡顿的操作事件，从而查找卡顿原因。

可选的，可以获取上一次停止写入所述当前播放音频的数据的第一时间点、以及当前开始写入所述当前播放音频的数据的第二时间点；根据所述第二时间点以及所述第一时间点，确定停止写入所述当前播放音频的数据的第一时长；确定在所述第一时间点到所述第二时间点的时间段内读取共享缓冲区中的所述当前播放音频的数据所需的第二时长；将所述第一时长减去所述第二时长，计算得到差值作为卡顿时长。

例如，假设共享缓冲区中上次剩余的当前播放音频的数据可以播放100ms，并记录上次写入当前播放音频的数据时间戳为t1，当前写入当前播放音频的数据时记录时间戳t2。在t2-t1这段时间内，没有向共享缓冲区写入当前播放音频的数据。共享缓冲区只能播放100ms，假设t2-t1为1000ms，则下一次写入数据需要等待1000ms，因此卡顿时长为900ms。

可选的，可以向服务器发送卡顿的相关信息，服务器接收到相关信息之后，可以根据相关信息确定解决方案，并向装置返回解决方案，以便用户设备可以及时解决出现卡顿的问题。其中，相关信息可以包括出现卡顿时的操作记录以及卡顿时长等等。

在本申请实施例中，首先使用监控拦截函数对数据结构体进行监控，然后获取数据结构体中所记录的当前播放音频的数据的写入位置处的第一偏移地址、以及当前播放音频的数据的读取位置处的第二偏移地址；最后根据第一偏移地址以及第二偏移地址，确定当前播放音频的数据的播放状态。通过使用监控拦截函数对当前播放情况进行监控，从而可以对当前播放状况进行准确判断，以便及时上报相关信息，从而提高解决问题的效率。

请继续参考图6，图6是本申请实施例提出的一种音频播放监控设备的结构示意图。如图所示，该音频播放监控设备可以包括：至少一个处理器601，至少一个通信接口602，至少一个存储器603和至少一个通信总线604。

其中，处理器601可以是中央处理器单元，通用处理器，数字信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理器和微处理器的组合等等。通信总线604可以是外设部件互连标准pci总线或扩展工业标准结构eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信总线604用于实现这些组件之间的连接通信。其中，本申请实施例中设备的通信接口602用于与其他节点设备进行信令或数据的通信。存储器603可以包括易失性存储器，例如非挥发性动态随机存取内存(nonvolatilerandomaccessmemory，nvram)、相变化随机存取内存(phasechangeram，pram)、磁阻式随机存取内存(magetoresistiveram，mram)等，还可以包括非易失性存储器，例如至少一个磁盘存储器件、电子可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、闪存器件，例如反或闪存(norflashmemory)或是反及闪存(nandflashmemory)、半导体器件，例如固态硬盘(solidstatedisk，ssd)等。存储器603可选的还可以是至少一个位于远离前述处理器601的存储装置。存储器603中存储一组程序代码，且处理器601执行存储器603中上述数据服务器所执行的程序。

使用监控拦截函数对当前播放音频的数据结构体进行监控，其中，所述数据结构体用于记录所述当前播放音频的数据的读写地址；

获取所述数据结构体中所记录的所述当前播放音频的数据的写入位置处的第一偏移地址、以及所述当前播放音频的数据的读取位置处的第二偏移地址；

根据所述第一偏移地址确定写入的所述当前播放音频的数据的第一数据大小、以及根据所述第二偏移地址确定读取的所述当前播放音频的数据的第二数据大小；

根据所述第一数据大小以及所述第二数据大小，确定所述当前播放音频的数据的播放状态。

可选的，处理器601还用于执行如下操作：

当所述第一数据大小小于所述第二数据大小时，确定所述当前播放音频的数据的所述播放状态为卡顿状态。

可选的，处理器601还用于执行如下操作：

获取上一次停止写入所述当前播放音频的数据的第一时间点、以及当前开始写入所述当前播放音频的数据的第二时间点；

根据所述第二时间点以及所述第一时间点，确定停止写入所述当前播放音频的数据的第一时长；

确定在所述第一时间点到所述第二时间点的时间段内读取共享缓冲区中的所述当前播放音频的数据所需的第二时长；

将所述第一时长减去所述第二时长，计算得到差值作为卡顿时长。

可选的，处理器601还用于执行如下操作：

获取所述数据结构体中所记录的共享缓冲区的空间大小；

根据所述共享缓冲区的所述空间大小，在所述共享缓冲区内循环写入所述当前播放音频的数据以及读取所述当前播放音频的数据。

可选的，处理器601还用于执行如下操作：

获取在所述当前播放音频的数据发生卡顿时的操作记录；

根据所述操作记录，确定引起所述当前播放音频的数据发生卡顿的操作事件。

可选的，处理器601还用于执行如下操作：

显示提示信息，所述提示信息用于提醒用户所述当前播放音频的数据的所述播放状态。

进一步的，处理器还可以与存储器和通信接口相配合，执行上述申请实施例中音频播放监控装置的操作。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。