音频数据传输的方法、装置、芯片和电子设备与流程

本申请实施例涉及无线通信技术领域，并且更具体地，涉及一种音频数据传输的方法、装置、芯片和电子设备。

背景技术：

随着移动终端技术、芯片技术的飞速发展，耳机市场得到了迅猛的发展，尤其是无线耳机市场。在诸多无线耳机产品中，真无线立体声（truewirelessstream，tws）耳机可以实现左右声道的立体声播放，在便于佩戴的同时为用户提供了优质的播放音质，因此得到了广大消费者的青睐。

目前，用户对tws耳机的时延要求较高，因此，如何减小音频数据在耳机端的传输时延，是一项亟待解决的问题。

技术实现要素：

本申请实施例提供一种音频数据传输的方法、装置、芯片和电子设备，可以减小音频数据的传输时延。

第一方面，提供了一种音频数据传输的方法，所述方法包括：第一端通过蓝牙链路，接收第三端发送的目标音频数据，所述目标音频数据用于得到第一音频数据，所述第一音频数据用于在第二端侧进行播放；所述第一端通过低功耗同步leisoc链路，向所述第二端传输所述第一音频数据。

在一些可能的实现方式中，所述方法还包括：所述第一端根据所述目标音频数据，得到第二音频数据；所述第一端根据所述第二音频数据的原始起播点、所述leisoc链路的传输时隙、所述蓝牙链路的传输时隙和刷新超时ft，确定所述第二音频数据的起播点，其中，所述第二音频数据的原始起播点为根据蓝牙音频传输模型协定a2dp协议确定的起播点；

所述第一端通过低功耗同步leisoc链路，向所述第二端传输所述第一音频数据，包括：所述第一端在所述第二音频数据的原始起播点处，通过所述leisoc链路，向所述第二端传输所述第一音频数据。

在一些可能的实现方式中，所述第一端根据所述第二音频数据的原始起播点、所述leisoc链路的传输时隙、所述蓝牙链路的传输时隙和刷新超时ft，确定所述第二音频数据的起播点，包括：

所述第一端根据所述第二音频数据的原始起播点、所述leisoc链路的传输时隙、le异步无连接acl链路的传输时隙、所述蓝牙链路的传输时隙和刷新超时ft，确定所述第二音频数据的起播点；

所述第二音频数据的起播点满足公式：

t=k+s+（ft-1）*i

其中，t为所述第二音频数据的起播点，k为所述第二音频数据的原始起播点，s为所述leisoc链路的传输时隙和所述leacl链路的传输时隙之和，i为所述蓝牙链路的传输时隙、所述leisoc链路的传输时隙以及所述leacl链路的传输时隙之和。

在一些可能的实现方式中，i=10ms。

在一些可能的实现方式中，s=2.5ms。

在一些可能的实现方式中，所述方法还包括：所述第一端通过所述leacl链路，向所述第二端发送请求信息，所述请求信息用于请求建立所述leisoc链路。

在一些可能的实现方式中，在建立所述leisoc链路之前，所述方法还包括：所述第一端建立与所述第三端之间的所述蓝牙链路。

在一些可能的实现方式中，在所述第一端向所述第二端传输所述第一音频数据之前，所述方法还包括：所述第一端采用低复杂度lc3编码格式，对所述第一音频数据进行编码。

在一些可能的实现方式中，所述方法还包括：所述第一端切换为所述第二端，其中，在所述第一端切换为所述第二端的过程中，所述第一端和所述第二端之间不停止所述第一音频数据的传输。

在一些可能的实现方式中，所述第一端传输所述第一音频数据的码率为96kbps。

在一些可能的实现方式中，所述第三端不支持低功耗音频标准。

第二方面，提供了一种音频数据传输的方法，所述方法包括：第二端通过低功耗同步leisoc链路，接收第一端发送的第一音频数据，其中，所述第一音频数据用于在所述第二端侧进行播放，所述第一音频数据为所述第一端根据第三端发送的目标音频数据得到的音频数据，所述第一端与所述第三端之间通过蓝牙链路进行连接。

在一些可能的实现方式中，所述第一音频数据为所述第一端对所述目标音频数据进行解码得到的部分音频数据。

在一些可能的实现方式中，所述方法还包括：所述第二端根据接收到所述第一音频数据的时间点或所述第一端发送所述第一音频数据的时间点、所述leisoc链路的传输时隙、所述蓝牙链路的传输时隙以及刷新超时ft，确定所述第一音频数据的起播点。

在一些可能的实现方式中，所述第二端根据接收到所述第一音频数据的时间点或所述第一端发送所述第一音频数据的时间点、所述leisoc链路的传输时隙、所述蓝牙链路的传输时隙以及刷新超时ft，确定所述第一音频数据的起播点，包括：所述第二端根据接收到所述第一音频数据的时间点或所述第一端发送所述第一音频数据的时间点、所述leisoc链路的传输时隙、le异步无连接acl链路的传输时隙、所述蓝牙链路的传输时隙以及刷新超时ft，确定所述第一音频数据的起播点；

所述第一音频数据的起播点满足公式：

t=k+s+（ft-1）*i

其中，t为所述第一音频数据的起播点，k为所述第二端接收到所述第一音频数据的时间点或所述第一端发送所述第一音频数据的时间点，s为所述leisoc链路的传输时隙和所述leacl链路的传输时隙之和，i为所述蓝牙链路的传输时隙、所述leisoc链路的传输时隙以及所述leacl链路的传输时隙之和。

在一些可能的实现方式中，i=10ms。

在一些可能的实现方式中，s=2.5ms。

在一些可能的实现方式中，所述方法还包括：所述第二端通过所述leacl链路，接收所述第一端发送的请求信息，所述请求信息用于请求建立所述leisoc链路。

在一些可能的实现方式中，所述第一音频数据是采用低复杂度lc3编码格式编码的音频数据。

在一些可能的实现方式中，所述方法还包括：所述第二端切换为第一端，其中，在所述第二端切换为所述第一端的过程中，所述第一端和所述第二端之间不停止所述第一音频数据的传输。

在一些可能的实现方式中，所述第三端不支持低功耗音频标准。

在一些可能的实现方式中，所述第三端不支持低功耗音频标准。

第三方面，提供了一种音频数据传输的装置，所述装置为第一端，用于执行上述第一方面或其各实现方式中的方法。

具体地，该第一端包括用于执行上述第一方面或其各实现方式中的方法的功能模块。

第四方面，提供了一种音频数据传输的装置，所述装置为第二端，用于执行上述第二方面或其各实现方式中的方法。

具体地，该第二端包括用于执行上述第二方面或其各实现方式中的方法的功能模块。

第五方面，提供了一种芯片，用于执行上述第一方面的音频数据传输的方法，包括存储器和处理器；

存储器与处理器耦合；

存储器，用于存储程序指令；

处理器，用于调用存储器存储的程序指令，使得芯片执行上述第一方面的音频数据传输的方法。

第六方面，提供了一种芯片，用于执行上述第二方面的音频数据传输的方法，包括存储器和处理器；

存储器与处理器耦合；

存储器，用于存储程序指令；

处理器，用于调用存储器存储的程序指令，使得芯片执行上述第二方面的音频数据传输的方法。

第七方面，提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序。其中，当所述计算机程序被处理器执行时，使得所述处理器执行第一方面或第一方面的任意可能的实现方式中的方法。

第八方面，提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序。其中，当所述计算机程序被处理器执行时，使得所述处理器执行第二方面或第二方面的任意可能的实现方式中的方法。

第九方面，提供了一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述第一方面或第一方面的任意可能的实现方式中的方法。

第十方面，提供了一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述第二方面或第二方面的任意可能的实现方式中的方法。

第十一方面，提供了一种电子设备，所述电子设备包括：上述第三方面或第三方面的任意可能的实现方式中的主设备；上述第四方面或第四方面的任意可能的实现方式中的副设备；

其中，所述主设备通过蓝牙链路与所述主设备连接，所述主设备和所述副设备之间存在至少一个无线通信链路，所述至少一个无线通信链路包括低功耗leisoc链路。

上述技术方案，第三端（如源设备）和第一端（如主设备）之间通过蓝牙链路传输音频数据，且第一端通过leisoc链路向第二端（如副设备）传输音频数据，这样，第一端向第二端发送的音频数据的送达时间是准确且可预期的，因此第二端不需要对音频数据做大量的缓存就可以做到同步，从而可以减小音频数据传输的时延。

附图说明

图1是目前的一种基于蓝牙音频方案的拓扑示意性图。

图2是目前另一种基于蓝牙音频方案的拓扑示意性图。

图3是目前再一种基于蓝牙音频方案的拓扑示意性图。

图4是本申请实施例的音频数据传输的示意性流程图。

图5是本申请实施例的拓扑示意性图。

图6是本申请实施例的bt链路和le链路的时隙分配图。

图7是本申请实施例的目标音频数据传输的流程图。

图8是本申请实施例的主设备和副设备进行角色切换的示意性图。

图9是本申请实施的音频数据传输的装置的示意性框图。

图10是本申请实施的音频数据传输的装置的示意性框图。

图11是本申请实施例的电子设备的示意性框图。

图12是本申请实施例的芯片的示意性框图。

图13是本申请实施例的芯片的示意性框图。

具体实施方式

下面将结合附图，对本申请实施例中的技术方案进行描述。

目前，市面上的部分耳机已经实现了蓝牙音频数据的无线立体声传输，在兼顾音频数据质量的同时没有了线缆的束缚，典型的拓扑如图1所示。

如图1所示的拓扑由可以自由主从切换的主耳机和副耳机组成，其中，主耳机与源设备通过蓝牙（bluetooth，bt）链路（link）直接连接，例如，源设备可以为手机，主耳机和副耳机通过低功耗（lowenergy，le）链路连接，且主耳机可以通过与副耳机的连接引导副耳机对主耳机与源设备链路的监听，以实现一带多的通信拓扑，这样主耳机和副耳机可以同时接收到源设备发送的音频数据，从而实现一发多收的机制。之后，主耳机和副耳机将音频数据进行解交织，从而可以呈现出无线立体声的效果。

图2是另一种基于蓝牙音频方案的拓扑示意性图。可以看到，主耳机与源设备直接连接，同时主耳机与副耳机同样建立了连接。当主耳机接收到源设备发送的音频数据后，主耳机不对接收的音频数据做任何处理，可以直接通过btlink或低频转发技术（lowbandbluetoothretransmissiontechnology，lbrt）链路转发给副耳机。

由于源设备将音频数据发送给主耳机后，主耳机再将音频数据转发给副耳机，因此，该方案的延时较大，且会严重浪费无线带宽。此外，该方案中，主耳机和副耳机播放音频数据的起播点很难同步，会影响用户的听感。

图3为另一蓝牙音频方案的拓扑示意性图。在该方案中，源设备通过bt链路同时与主耳机和副耳机建立连接，源设备可以将音频数据分别传输给主耳机和副耳机，同时主耳机和副耳机可以对接收到的音频数据同步播放。

该蓝牙音频方案对源设备的限制较大，源设备必须使用该方案的定制化芯片，且无法与其他蓝牙标准协议兼容。

图4是本申请实施例的音频数据传输的方法的示意性流程图，图4的方法100可以由第三端、音频数据的播放端中的第一端以及音频数据的播放端中的第二端执行，该第一端、第二端、第三端可以为芯片或者是设备，该第一端、第二端和第三端例如分别可以为上述内容提到的主设备、副设备和源设备。下面以第一端、第二端和第三端分别为上主设备、副设备和源设备为例描述本申请实施例。

作为示例而非限定，源设备可以为终端设备、手机、平板电脑、笔记本电脑、台式机电脑、游戏设备、车载电子设备或穿戴式智能设备等便携式或移动计算设备。主设备可以为与源设备建立有用于音频数据传输的无线通信链路的蓝牙耳机、助听器、蓝牙音箱等。副设备可以为不与源设备直接连接的蓝牙耳机、助听器、蓝牙音箱等。示例性地，主设备可以为tws耳机中的主耳机，副设备可以为tws耳机中的副耳机。

图5是方法100所适用的一种可能的拓扑图。可以看到，源设备和主设备之间通过bt链路连接，主设备和副设备之间通过低功耗（lowenergy，le）同步（isochronous，isoc）链路进行连接。

其中，源设备可以支持le音频（audio）标准，也可以不支持leaudio标准，即本申请实施例可以兼容不支持leaudio标准的电子设备。如此，本申请实施例可以提高源设备的兼容性。

在一定时间内leisoc链路可以允许重传，也就是说，若主设备通过leisoc链路没有成功向副设备传输音频数据，则主设备可以重传该音频数据。若主设备和副设备为tws耳机，由于两只耳机间距离通常比较近，音频数据传输可以有很高的传输成功率，比如90%以上，则重传次数可以为1。

上文提到的一定时间可以指刷新超时（flushtimeout，ft），在创建图5所示的拓扑时可以确定ft，ft的取值为正整数，如ft可以为1、2或3等，ft的单位是interval。优选地，ft=1。

为了描述方便，本申请实施例将主设备和副设备之间的链路称为第一链路。可选地，第一链路可以包括leisoc链路；或者，第一链路可以包括leisoc链路和le异步无连接（asynchronousconnectionless，acl）链路。

其中，leacl链路主要可以用于传输控制信令，且接收到对端的应答之后才可以发送下一条控制信令。leisoc链路主要可以作为主设备和副设备之间音频数据的传输通道，且可以用于保证数据传输时序、数据传输同步和播放同步。

在本申请实施例中，bt链路和第一链路的总传输时隙（即bt链路的传输时隙和第一链路的传输时隙之和）可以为10ms。本申请实施例使用625μs作为传输单位，即一个时隙为625μs。也就是说，bt链路和第一链路共可以占用16个时隙。当然，本申请实施例也可以将bt链路和第一链路的总传输时隙称为通讯间隔（interval）或者isocinterval或者调度周期。

参考图6，时隙例如可以理解为：源设备向主设备发送音频数据的时刻与主设备针对该音频数据向源设备发送应答的时刻之间的间隔。图6中标识的m表示源设备向主设备发送的数据包，该数据包可以包括音频数据，m后面的数字表示这个数据包的序号，不同的序号表示不同的数据包。标识的y表示主设备对源设备发送的数据包的应答，通常是空包，仅仅作为对源设备发送的数据包的应答，因此，图6中没有强调主设备对数据包应答的序号。

图6中的第一链路包括leisoc链路和leacl链路，子（sub）isoc1为主设备第一次通过leisoc链路向副设备传输音频数据的时隙，subisoc2为主设备通过leisoc链路重传该音频数据的时隙。可以看到，第一链路和bt链路的总传输时隙为10ms，占用了16个时隙。

基于leaudio标准，当主设备通过leisoc链路向副设备传输音频数据的码率为124kbps时，主设备侧和副设备侧播放的音频数据的音质最好。然而，在主设备向副设备传输音频数据的码率为124kbps时，第一链路占用的传输时隙较多，例如可以达到3.75ms。在这种情况下，bt链路占用的传输时隙会减小，使得蓝牙链路的带宽可能不能保证源设备和主设备之间的音频数据的传输，从而会影响该音频数据的传输质量。因此，本申请实施例的主设备向副设备传输音频数据的码率为124kbps以下。在该情况下，当主设备和副设备之间传输的音频数据的传输码率为96kbps时，主设备和副设备之间传输的音频数据的质量最高，即在主设备侧和副设备侧播放的音频数据的音质最好。因此，本申请实施例将主设备和副设备之间传输的音频数据的传输码率设置为96kbps。如此，可以提高用户的音质体验。

主设备和副设备之间传输的音频数据的传输码率为96kbps，表明主设备和副设备之间一秒可以传输12（96k/8=12k）个字节（byte）的音频数据，即10ms可以传输120个byte的音频数据，则该音频数据所在的协议数据单元（protocoldataunit，pdu）占用120+2+4=126个byte。其中，2为该pdu的头部（header）占用的byte，4为消息完整性校验（messagesintegritycheck，mic）占用的byte。进一步地，前导码（preamble）占用2个byte，接入地址（access-address）占用4个byte，循环冗余校验（cyclicredundancycheck，crc）占用3个byte，则共占用126+2+4+3=135个byte。

副设备针对该pdu的应答（图6中未示出）占用2个字节，进一步地，preamble占用2个byte，access-address占用4个byte，crc占用3个byte，则共占用2+2+4+3=11个byte。

主设备发送给副设备的pdu和副设备针对该pdu的应答共占用146个byte，即146*8=1168个比特。由于为2m物理层（phy），则主设备发送给副设备的pdu和副设备针对该pdu的应答的传输时间共为1168/2=584μs。进一步地，由于一次收发需间隔150μs，因此，leisoc链路的单次传输时间可以为584+150*2=884μs。

根据前文所述，leisoc链路有一次的重传机会，则leisoc链路的最大传输时间可以为884μs*2=1768μs。应理解，主设备通过leisoc链路向副设备发送音频数据时，大多数情况下都是一次性发送成功，重传的机会用到的不多，所以leisoc链路的最优传输时间可以为884μs。

leacl链路的最大传输时间可以为636μs，则第一链路的最大传输时间可以为1768μs+636μs=2404μs。基于此，第一链路可以占用4个时隙，即第一链路的传输时隙可以设置为2.5ms。

再次参考图6，bt链路占用了12个时隙，第一链路占用了4个时隙，即第一链路的传输时隙为2.5ms，这样可以保证通过bt链路以及通过第一链路传输的音频数据的质量。

应理解，图6仅是示例，不应构成对本申请实施例的限定。

在音频数据传输的过程中，主设备需要兼顾两条不同的链路，即与源设备之间的bt链路以及与副设备之间的第一链路。为了避免该两条不同的链路的相互影响，应尽量避免两条链路之间的传输时隙重叠。再次参考图6，可以看到，bt链路的传输时隙为16个时隙中的前12个时隙，第一链路的传输时隙为后4个时隙，图6中对bt链路的传输时隙分配以及对第一链路的传输时隙分配，避免了两条不同的链路之间的传输时隙重叠。

也就是说，主设备在与副设备通信时，不与源设备进行通信。比如，主设备在与副设备通信时，主设备可以关闭与源设备之间进行通信的收发器。在该情况下，源设备向主设备发送音频数据后接收不到来自主设备的应答，此时，源设备可以自动进行该音频数据的重传。

再次参考图6，在主设备和副设备之间的第一链路的传输时隙中，源设备向主设备发送m7数据包，由于在第一链路的传输时隙中，主设备在和副设备进行通信，不与源设备进行通信，因此，主设备不向源设备进行针对m7数据包的应答。源设备未接收到主设备的应答，则源设备继续向主设备发送m7数据包。

或者，主设备在与源设备通信时，不与副设备进行通信。

下面以本申请实施例应用于tws耳机的场景为例，先详细介绍图5所示的拓扑的构建过程。

步骤1：多个sink设备在加入拓扑前处于低功耗模式，等待被唤醒。在sink设备被唤醒，例如打开耳机充电盒后，多个sink设备间可以通过除了蓝牙连接之外的其他物理连接进行配置，以相互绑定对端设备地址。例如，多个sink设备包括第一设备和第二设备，第一设备和第二设备可以相互绑定对端设备地址。

步骤2：第一设备被从耳机充电盒取出，进行le广播。

其中，本申请实施例对第一设备进行le广播的时间不作具体限定。比如，本申请实施例可以规定第一设备进行le广播的时间为1ms。再比如，第一设备进行le广播的时间可以由第一设备的产品形态决定。

步骤3：在第一设备进行le广播后，若一定时间内有支持le音频（audio）标准的源设备建立与第一设备之间的连接，则第一设备执行现有的leaudio方案。

若一定时间内没有支持leaudio标准的源设备尝试建立与第一设备之间的连接，则第一设备可以使用步骤1中绑定的地址，发送广播。

可选地，第一设备可以持续广播1.28s。

可选地，第一设备可以发送高占空比定向广播。如此，只有与第一设备绑定过设备地址的sink设备才有可能与第一设备建立连接，且第一设备发送高占空比广播，可以节省与其他sink设备建立连接的时间。

步骤4：第一设备广播完之后，启动le扫描（scan）以扫描其他sink设备。若第一设备扫描到了绑定过设备地址的sink设备正在广播，例如，该sink设备为第二设备，则第一设备可以与第二设备建立leacl链路，其中，第一设备为主设备，第二设备为副设备。

若第一设备在广播的过程中，被绑定过设备地址的其他sink设备扫描到，例如，被第二设备扫描到，则第一设备与第二设备建立leacl链路，第一设备为副设备，第二设备为主设备。

其中，第二设备可以为在第一设备之前结束广播的设备，例如，第二设备可以是先从耳机充电盒取出的sink设备，即第二设备可以是在第一设备广播之前广播的设备。或者，第二设备也可以是在第一设备广播之后或者与第一设备同时广播的设备，在这种情况下，第二设备广播的持续时间可以比第一设备广播的持续时间短。

若在第一设备广播完且扫描完其他sink设备之后，第一设备没有扫描到绑定过设备地址的sink设备，则第一设备为主设备。

步骤5：主设备启动bt的配对连接过程，等待与支持bt的源设备建立bt连接。

若第一设备没有扫描到绑定过设备地址的sink设备，则第一设备可以在启动bt的配对连接过程的同时，再次扫描绑定过设备地址的其他sink设备，或者，可以重新进行广播。

步骤6：在源设备与主设备建立了bt链路、主设备与副设备建立了leacl链路之后，主设备可以通过leacl链路，向副设备发送请求信息，该请求信息用于请求建立leisoc链路。在主设备和副设备协商之后，主设备和副设备之间建立起leisoc链路。

应理解，上述步骤1-步骤6仅是图5所示的拓扑的示例性构建过程，并不对本申请实施例构成任何限制。

在拓扑构建完成之后，下面介绍方法100的实现过程。如图4所示，该方法100可以包括以下内容中的至少部分内容。

在110中，源设备通过bt链路，向主设备发送目标音频数据。

相应地，主设备可以通过bt链路接收到源设备发送的目标音频数据。

其中，目标音频数据可以用于得到第一音频数据，第一音频数据用于在第二端侧进行播放。

当源设备支持leaudio标准时，源设备可以采用子带编码（sub-bandcoding，sbc）格式、高级音频编码（advancedaudiocoding，aac）格式、ldac编码格式、低复杂度（lowcomplexity，lc）3等编码格式对目标音频数据进行编码。

当源设备不支持leaudio标准时，源设备可以采用sbc、aac、ldac编码格式对目标音频数据进行编码。

如此，本申请实施例对源设备没有特别的要求，如果源设备支持leaudio标准的话，则可以执行leaudio方案或本申请实施例的方案；如果源设备不支持leaudio标准的话，则可以执行本申请实施例的方案。

主设备接收到目标音频数据后，可以先对目标音频数据进行解码。具体而言，主设备可以通过数字信号处理（digitalsignalprocessor，dsp）等其他硬件单元，将目标音频数据解码为可直接输出给数模转换器（digitaltoanalogconverter，dac）的脉冲编码调制（pulsecodemodulation，pcm）数据。

主设备对目标音频数据解码，除了可以得到第一音频数据之外，还可以得到第二音频数据，第二音频数据用于在主设备侧进行播放。

应理解，第一音频数据和第二音频数据都为pcm数据。

在120中，主设备通过leisoc链路，向副设备传输第一音频数据。

作为一种示例，主设备对目标音频数据解码后，暂时不确定哪些音频数据是在主设备侧播放，哪些音频数据在主设备侧进行播放。此时，主设备可以通过leisoc链路将解码得到的所有音频数据都传输给副设备，即主设备可以将第一音频数据和第二音频数据都通过leisoc链路都传输给副设备。

作为另一种示例，通常情况下，主设备解码后的pcm数据为立体声，此时，主设备可以对pcm数据进行解交织，即分离左右声道。之后，主设备可以将第二音频数据送入dac缓存准备播放，而将第一音频数据送入dsp或者其他硬件单元进行编码，并且将编码后的第一音频数据放入leisoc链路的发送缓存中。

由于主设备不需要将解码后的所有音频数据都发送给副设备，只需要将副设备对应的音频数据发送给副设备，从而可以避免对无线带宽的浪费。

副设备对应的音频数据可以理解为：若副设备为右耳机，则副设备对应的音频数据，即第一音频数据为右声道输出的音频数据。

可选地，主设备可以采用lc3编码格式对第一音频数据进行编码。

由于lc3编码格式是专门配合leisoc链路开发的编码格式，具有低延时、高音质、丢包弥补等优点，如此，可以减小音频数据传输的时延，且可以提高用户的音质体验。进一步地，由于lc3编码格式的压缩率较高，这样的话比如第一音频数据的大小为256字节，则主设备可以将第一音频数据压缩到128字节，从而可以进一步节省无线带宽，进一步地可以减小功耗。

当然，主设备也可以采用sbc、aac或ldac等编码格式对第一音频数据进行编码。

由于lc3编码格式的帧长为10ms，第一链路和bt链路的总传输时隙为10ms时，可以更好地配合lc3编码格式。

若当前只有主设备在工作，副设备没有工作，比如，副设备的电量耗尽或者用户将副设备又放回了充电盒中，则主设备可以丢弃第一音频数据，或者主设备可以根据应用配置在同一个扬声器上同时播放两个声道。

副设备接收到编码后的第一音频数据后，可以将编码后的第一音频数据通过dsp进行解码，然后将解码后的第一音频数据送入dac缓存准备播放。

若主设备通过leisoc链路没有成功向副设备传输第一音频数据，则主设备可以重传第一音频数据。

下面结合图7示例性地描述方法100。

如图7所示，主设备为左耳机，副设备为右耳机。源设备通过bt链路向主设备发送目标音频数据，其中，源设备通过aac编码格式对目标音频数据进行编码。主设备接收到目标音频数据后，对目标音频数据进行解码，得到pcm数据。然后，主设备对pcm数据进行解交织，得到左声道（ch_l）对应的第二音频数据和右声道（ch_r）对应的第一音频数据。主设备将第二音频数据dac缓存准备播放，并采用lc3编码格式对第一音频数据进行编码，然后通过leisoc链路将编码后的第一音频数据发送给副设备。副设备通过leisoc链路接收到编码后的第一音频数据之后，对编码后的第一音频数据进行解码，并将解码后的pcm数据（即第一音频数据）送入dac缓存准备播放。

在将音频数据传输完之后，主设备开始播放第二音频数据，且副设备开始播放第一音频数据。

由于主设备和副设备之间传输的是立体声音频数据，如果音频数据同步精度不高可能会导致左右声道出现声音不同步的问题，从而严重影响用户的听觉体验。

副设备解码得到第一音频数据后，主设备和副设备可以对第一音频数据和第二音频数据进行时间对齐，并且在相同的时间开始播放第一音频设备和第二音频数据。也就是说，第一音频数据的起播点和第二音频数据的起播点相同。

可选地，主设备和副设备可以根据leisoc协议规定的同步时间基准，对第一音频数据和第二音频数据进行时间对齐。

可选地，主设备和副设备可以以主设备和副设备之中的任意一个设备的时间为基准，对第一音频数据和第二音频数据进行时间对齐。

可选地，主设备和副设备可以协商好同步时间基准，以对第一音频数据和第二音频数据进行时间对齐。

需要说明的是，在本申请实施例中，除了主设备和副设备之间需要进行时钟同步，主设备和源设备之间也需要进行时钟同步。可选地，主设备可以以源设备为基准，在每一次音频数据收发时都进行时钟校准，从而可以避免不同设备间时钟不同步的问题。

可选地，本申请实施例可以利用leisoc链路同步传输的特性进行音频起播、音频同步操作，并且在每个时间单元进行实时音频同步，以完成精准的音频同步效果。示例性地，时间单元可以为时隙。

由于主设备和副设备之间需要进行音频数据的中转，音频数据中转过程需要额外的时间，主设备可以根据第二音频数据的原始起播点、第一链路的传输时隙、bt链路的传输时隙和ft，确定第二音频数据的起播点。

其中，第二音频数据的原始起播点为根据蓝牙音频传输模型协定（advancedaudiodistributionprofile，a2dp）协议确定的起播点。可选地，第二音频数据的原始起播点可以和源设备发送的目标音频数据的帧数有关，例如，第二音频数据的原始起播点可以为源设备向主设备发送了n帧目标音频数据后的时间点。第二音频数据的原始起播点的确定可以参考现有技术，本申请实施例不再详述。

需要说明的是，假设第一链路只包括leisoc链路，则第一链路的传输时隙为leisoc链路的传输时隙。

参考图6，若第一链路包括leisoc链路和leacl链路，则第一链路的传输时隙可以为leisoc链路的传输时隙和leacl链路的传输时隙之和。

可选地，第二音频数据的起播点可以满足如下公式：

t=k+s+（ft-1）*i

其中，t为第二音频数据的起播点，k为第二音频数据的原始起播点，s为第一链路的传输时隙，i为蓝牙链路和第一链路的传输时隙。

可选地，如图6所示，s可以等于2.5ms。

可选地，如图6所示，i可以等于10ms。

上述技术方案，若s=2.5ms，ft=1，则源设备将目标音频数据发送给主设备后，主设备和副设备可以在源设备将目标音频数据发送给主设备后的2.5ms播放第一音频设备和第二音频数据。通常情况下，bt链路的传输时延在100ms以上，仅仅增加2.5ms对整体时延影响不大。

主设备可以在第二音频数据的原始起播点处向副设备发送第一音频数据，副设备接收到第一音频数据后，可以根据接收到第一音频数据的时间点、第一链路的传输时隙、bt链路的传输时隙以及ft，确定第一音频数据的起播点。

可选地，第一音频数据的起播点t可以满足如下公式：

t=k+s+（ft-1）*i

或者，k也可以为主设备向副设备发送第一音频数据的时间点。示例性地，主设备可以通过leacl链路告诉副设备自己发送第一音频数据的时间点。再示例性地，在本申请实施例中，主设备发送第一音频数据的时间点和副设备接收到第一音频数据的时间点可以相同，即本实施例中，k也可以为副设备接收到第一音频数据的时间点。

上述技术方案可以实现第一音频数据和第二音频数据的同步播放。

需要说明的是，本申请实施例的音频同步仅涉及主设备和副设备之间的同步，并不涉及主设备和源设备之间的音频同步。

还需要说明的是，若主设备和副设备之间的传输时延较小，则可以忽略主设备和副设备之间的传输时延，即本申请实施例可以认为主设备向副设备发送第一音频数据的时间点与副设备接收到第一音频数据的时间点相同。若主设备和副设备之间的传输时延较大，则副设备可以在主设备向副设备发送第一音频数据的时间点和副设备接收到第一音频数据的时间点之间任意选择一个时间点作为k。

对于包括主设备和副设备的电子设备来说，可能会发生但不限于以下至少一种状况：用户将主设备收了起来，比如将主耳机放进了充电盒；主设备和副设备的耗电量不一致，比如，主设备的耗电速度较快，当主设备的电量过低时，即使副设备的电量充足，主设备和副设备均无法继续被用户使用。

因此，方法100还可以包括：主设备和副设备之间进行角色切换，即原主设备切换为新的副设备，原副设备切换为新的主设备。

在本申请实施例中，在主设备和副设备进行角色切换的过程中，主设备和副设备之间通过leisoc链路的音频数据传输并不会停止。例如，在主设备和副设备进行角色切换时，主设备可以继续通过leisoc链路向副设备发送第一音频数据，副设备可以继续通过leisoc链路接收主设备发送的第一音频数据。应理解，此处的“主设备和副设备之间通过leisoc链路的音频数据传输并不会停止”中的“音频数据”除了可以为第一音频数据之外，还可以为其他的音频数据，本申请实施例对此不作具体限定。

如此，在主设备和副设备进行角色切换时，可以保证主设备和副设备之间的音频数据的连续传输。

在主设备和副设备进行角色切换的过程中，主设备可以将与源设备之间的bt链路转移到副设备中。具体而言，主设备在获取到与源设备之间的bt链路的链路参数后，可以向副设备发送第一信息，该第一信息包括链路参数。

可选地，主设备可以通过leacl链路向副设备发送第一信息。

可选地，链路参数可以包括但不限于时间信息、信道信息、跳频信息、加密信息、接入码等。

副设备接收到链路参数后，可以根据链路参数，尝试与源设备进行通信传输。若副设备已经开始和源设备进行通信传输，则表明副设备已经切换为新的主设备。

接下来，副设备可以向原主设备发送第二信息，该第二信息用于指示副设备已经切换为新的主设备。可选地，副设备可以通过leacl链路向原主设备发送第二信息。原主设备接收到第二信息后，可以断开和源设备之间的bt链路，切换为新的副设备。

可以看到，副设备需要根据主设备和源设备之间的链路参数切换为新的主设备。若主设备将链路参数告诉给副设备之后，主设备再与源设备进行通信，则链路参数将会发生改变。这样的话，副设备根据接收到的链路参数是不可能与源设备通信成功的。

因此，在主设备获取到链路参数和副设备与源设备之间开始进行通信传输之前，主设备可以停止与源设备之间的通信传输。如此，可以保证副设备根据接收到链路参数可以与源设备之间进行通信传输。

可选地，在主设备和副设备进行角色切换之前，主设备可以通过leacl链路，向副设备发送切换请求信息，该切换请求信息用于请求与副设备之间进行角色切换。

若主设备通过leacl链路接收到了副设备发送的切换请求确认信息，且该切换请求确认信息用于指示副设备同意主设备的切换请求，则主设备和副设备之间可以开始进行角色切换。

若主设备通过leacl链路接收到了副设备发送的切换请求确认信息，但该切换请求确认信息用于指示副设备不同意主设备的切换请求，或者，主设备在预设时间内未接收到副设备发送的切换请求确认信息，则主设备和副设备之间不进行角色切换。

其中，预设时间可以是协议规定的，也可以是主设备和副设备约定好的。

在主设备未与副设备角色切换成功的情况下，主设备可以再次启动与源设备之间的通信传输，然后可以重新进行与副设备之间的角色切换。

主设备未与副设备角色切换成功可能包括以下几种情况：

（1）副设备未同意主设备的切换请求；

（2）副设备同意了主设备的切换请求，但副设备没有成功切换为新的主设备；

（3）副设备成功切换为新的主设备，但主设备没有接收到副设备发送的第二信息；

（4）副设备成功切换为新的主设备，且主设备接收到了副设备发送的第二信息，但主设备没有成功切换为新的副设备；

（5）主设备在告诉了副设备链路参数后，且副设备还没有切换为新的主设备，主设备与源设备进行了通信。

应理解，若主设备和源设备之间长时间没有进行通信传输，则主设备和源设备之间的bt链路有可能会被刷掉，因此，若主设备未与副设备角色切换成功，主设备需要再次启动与源设备之间的通信传输。

图8为主设备和副设备之间进行角色切换的具体步骤。

步骤1：主设备向副设备发送切换请求信息，该切换请求信息用于请求与所述副设备之间进行角色切换。

步骤2：副设备向主设备发送切换请求确认信息。

若该切换请求确认信息用于指示副设备同意主设备的切换请求，则主设备执行后面的步骤；若该切换请求信息用于指示副设备拒绝主设备的切换请求，则角色切换流程结束。

步骤3：主设备获取链路参数，并确定角色切换的锚点，之后，主设备通过leacl链路向副设备发送第二信息，该第二信息用于指示副设备根据链路参数与源设备之间开始进行通信传输，即通知副设备进行角色转换。

步骤4：副设备根据链路参数，尝试与源设备进行通信传输。

若副设备与源设备通信传输成功，即副设备切换为了新的主设备，则向主设备发送第二信息，以通知原副设备已经切换为了新的主设备。比如，原副设备向原主设备发送肯定应答（acknowledge，ack），则原主设备执行步骤5。

若副设备没有与源设备通信成功，比如，副设备向主设备发送否定应答（negativeacknowledgement，nck），则主设备执行步骤6。

在步骤3和步骤4中，原主设备不与源设备进行通信传输。

步骤5：原主设备根据确定的锚点切换为新的副设备。其中，锚点可以理解为两个设备之间约定执行某个动作的时间点。例如，本申请实施例中的锚点可以为原主设备和原副设备之间约定的原主设备切换为新的副设备的时间点。

至此，主设备和副设备之间的角色切换过过程结束。

步骤6：主设备通过bt链路与源设备进行通信传输，重新进行与副设备之间的角色切换。

本申请实施例，第三端（如源设备）和第一端（如主设备）之间通过蓝牙链路传输音频数据，且第一端通过leisoc链路向第二端（如副设备）传输音频数据，这样，第一端向第二端发送的音频数据的送达时间是准确且可预期的，因此第二端不需要对音频数据做大量的缓存就可以做到同步，从而可以减小音频数据传输的时延。

在本申请实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

并且，在不冲突的前提下，本申请描述的各个实施例和/或各个实施例中的技术特征可以任意的相互组合，组合之后得到的技术方案也应落入本申请的保护范围。

上文详细描述了本申请实施例的音频数据传输的方法，下面将描述本申请实施例的音频数据传输的装置。应理解，本申请实施例中的音频数据传输的装置可以执行本申请实施例中的音频数据传输的方法，具有执行相应方法的功能。

图9示出了本申请实施例的音频数据传输的装置200的示意性框图。如图9所示，该音频数据传输的装置200可以包括：

通信单元210，用于通过蓝牙链路，接收第三端发送的目标音频数据，目标音频数据用于得到第一音频数据，第一音频数据用于在第二端侧进行播放。

通信单元210还用于，通过leisoc链路，向第二端传输第一音频数据。

可选地，在本申请实施例中，如图9所示，装置200还包括：处理单元220，用于根据目标音频数据，得到第二音频数据；根据第二音频数据的原始起播点、第一链路的传输时隙、蓝牙链路的传输时隙和ft，确定第二音频数据的起播点，其中，第二音频数据的原始起播点为根据a2dp协议确定的起播点；

通信单元210具体用于：在第二音频数据的原始起播点处，通过leisoc链路，向第二端传输第一音频数据。

可选地，在本申请实施例中，处理单元220具体用于：根据第二音频数据的原始起播点、leisoc链路的传输时隙、leacl链路的传输时隙、蓝牙链路的传输时隙和ft，确定第二音频数据的起播点；

第二音频数据的起播点满足公式：

t=k+s+（ft-1）*i

其中，t为第二音频数据的起播点，k为第二音频数据的原始起播点，s为leisoc链路的传输时隙和leacl链路的传输时隙之和，i为蓝牙链路的传输时隙、leisoc链路的传输时隙之和以及leacl链路的传输时隙。

可选地，在本申请实施例中，i=10ms。

可选地，在本申请实施例中，s=2.5ms。

可选地，在本申请实施例中，通信单元210还用于：通过leacl链路，向第二端发送请求信息，请求信息用于请求建立leisoc链路。

可选地，在本申请实施例中，如图9所示，装置200还包括建立单元230，建立单元230用于：在建立leisoc链路之前，建立与第三端之间的所述蓝牙链路。

可选地，在本申请实施例中，如图9所示，装置200还包括：编码单元240，用于在通信单元210向第二端传输第一音频数据之前，采用lc3编码格式，对第一音频数据进行编码。

可选地，在本申请实施例中，如图9所示，装置200还包括：切换单元250，用于切换为所述第二端，其中，在切换单元250切换为第二端的过程中，通信单元210和第二端之间不停止第一音频数据的传输。

可选地，在本申请实施例中，通信单元210传输第一音频数据的码率为96kbps。

可选地，在本申请实施例中，第三端不支持低功耗音频标准。

应理解，该音频数据传输的装置200可对应于方法100中的主设备，可以实现该方法100中的主设备的相应操作，为了简洁，在此不再赘述。

还应理解，图9所示的各个功能模块之间的连接可以是直接连接，也可以是间接连接。

图10示出了本申请实施例的音频数据传输的装置300的示意性框图。如图10所示，该音频数据传输的装置300可以包括：

通信单元310，用于通过低功耗leisoc链路，接收第一端发送的第一音频数据，其中，第一音频数据为第一端根据第三端发送的目标音频数据得到的音频数据，第一端与第三端之间通过蓝牙链路进行连接。

播放单元320，用于播放第一音频数据。

可选地，在本申请实施例中，第一音频数据为第一端对目标音频数据进行解码得到的部分音频数据。

可选地，在本申请实施例中，如图10所示，装置300还包括：处理单元330，用于根据通信单元310接收到第一音频数据的时间点或第一端发送第一音频数据的时间点、leisoc链路的传输时隙、蓝牙链路的传输时隙以及ft，确定第一音频数据的起播点。

可选地，在本申请实施例中，处理单元330具体用于：根据通信单元310接收到第一音频数据的时间点或第一端发送第一音频数据的时间点、leisoc链路的传输时隙、leacl链路的传输时隙、蓝牙链路的传输时隙以及ft，确定第一音频数据的起播点；

第一音频数据的起播点满足公式：

t=k+s+（ft-1）*i

其中，t为第一音频数据的起播点，k为通信单元310接收到第一音频数据的时间点或第一端发送第一音频数据的时间点，s为leisoc链路的传输时隙和leacl链路的传输时隙之和，i为蓝牙链路的传输时隙、leisoc链路的传输时隙以及leacl链路的传输时隙之和。

可选地，在本申请实施例中，i=10ms。

可选地，在本申请实施例中，s=2.5ms。

可选地，在本申请实施例中，通信单元310还用于：通过leacl链路，接收第一端发送的请求信息，请求信息用于请求建立leisoc链路。

可选地，在本申请实施例中，第一音频数据是采用lc3编码格式编码的音频数据。

可选地，在本申请实施例中，如图10所示，装置300还包括：切换单元340，用于切换为第一端，其中，在切换单元340切换为第一端的过程中，第一端和通信单元310之间不停止第一音频数据的传输。

可选地，在本申请实施例中，通信单元310接收第一音频数据的码率为96kbps。

可选地，在本申请实施例中，第三端不支持低功耗音频标准。

应理解，该音频数据传输的装置300可对应于方法100中的副设备，可以实现该方法100中的副设备的相应操作，为了简洁，在此不再赘述。

还应理解，图10所示的各个功能模块之间的连接可以是直接连接，也可以是间接连接。

本申请实施例还提供了一种电子设备。如图11所示，该电子设备400可以包括第一端410和第二端420。该第一端410可对应于方法100中的主设备，可以实现该方法100中的主设备的相应操作，该第二端420可对应于方法100中的副设备，可以实现该方法100中的副设备的相应操作，为了简洁，在此不再赘述。

本申请实施例还提供了一种芯片500，芯片500包括存储器510和处理器520；

存储器510与处理器520耦合；

存储器510，用于存储程序指令；

处理器520，用于调用存储器存储的程序指令，使得芯片执行上述任一实施例提出的音频数据传输的方法100中的主设备的相应操作。

本申请实施例还提供了一种芯片600，芯片600包括存储器610和处理器620；

存储器610与处理器620耦合；

存储器610，用于存储程序指令；

处理器620，用于调用存储器存储的程序指令，使得芯片执行上述任一实施例提出的音频数据传输的方法100中的副设备的相应操作。

本申请实施例提供的芯片其具体的实现过程及有益效果参见上述，在此不再赘述。

应理解，在本申请实施例和所附权利要求书中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请实施例。例如，在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“上述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

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

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。