CN116471351B - 通话音频数据的传输方法及装置 - Google Patents

Abstract

本申请实施例提供一种通话音频数据的传输方法以及装置，应用于第一电子设备，方法包括：响应于通话操作，与对端电子设备建立通话，第二电子设备作为通话的声音信号的输出以及输入设备，第一电子设备与第二电子设备处于多屏协同模式。将对端电子设备发送的通话音频下行数据存储在第一PCM设备，将第一PCM设备中的通话音频下行数据向第二电子设备传输，将第二电子设备发送的通话音频上行数据存储在第二PCM设备，将第二PCM设备中的通话音频上行数据向对端电子设备传输，响应于通话录音操作，将通话音频上行数据和通话音频下行数据存储在第三PCM设备，使用不同的PCM设备实现通话音频上行数据、通话音频下行数据的传输及录音，降低了复用PCM设备导致的冲突。

Description

通话音频数据的传输方法及装置

技术领域

本申请涉及通信技术领域，尤其涉及一种通话音频数据的传输方法及装置。

背景技术

基于蜂窝通信网络的通话功能，是手机常见的功能，但不支持蜂窝网络的电子设备不具备该功能。

而在多屏协同模式下，与手机等具备蜂窝通信的第一电子设备协同的第二电子设备，可以实现基于蜂窝通信网络的通话功能。

发明内容

本申请提供了一种通话音频数据的传输方法及装置，目的在于实现在不同电子设备之间传输通话音频数据。

为了实现上述目的，本申请提供了以下技术方案：

本申请的第一方面提供一种通话音频数据的传输方法，应用于第一电子设备，所述第一电子设备包括第一PCM设备，第二PCM设备和第三PCM设备，所述第一PCM设备，所述第二PCM设备和所述第三PCM设备用于缓存PCM音频数据，所述方法包括：响应于通话操作，与对端电子设备建立通话，第一电子设备与第二电子设备处于多屏协同模式。接收对端电子设备发送的通话音频下行数据，将通话音频下行数据存储在第一PCM设备中，且将第一PCM设备中的通话音频下行数据向第二电子设备传输，接收第二电子设备发送的通话音频上行数据，且将第二电子设备发送的通话音频上行数据存储在第二PCM设备，且将第二PCM设备中的通话音频上行数据向对端电子设备传输，响应于通话录音操作，将通话音频上行数据和通话音频下行数据存储在第三PCM设备。其中，第一PCM设备、第二PCM设备与第三PCM设备不同，可见，使用不同的PCM设备分别实现通话音频上行数据、通话音频下行数据的传输、以及录音，所以能够降低因复用PCM设备而导致PCM中缓存数据冲突的可能性。进一步的，也能够避免因解决冲突而导致的电子设备功耗增加的问题。

在某些实现方式中，所述与对端电子设备建立通话，包括：通过调制解调器Modem与所述对端电子设备建立通话，所述将所述通话音频下行数据存储在第一PCM设备，包括：通过打开第一PCM设备文件，打开所述第一PCM设备以及协同通话下行通路，所述协同通话下行通路用于连接所述第一PCM设备与所述Modem。通过第一PCM设备文件实现对第一PCM的打开，能够简化操作并与软件系统的操作逻辑统一，具有较好的兼容性。协同通话下行通路用于连接第一PCM设备与Modem，所以打开通路即可实现通话音频下行数据通过协同通话下行通路从Modem传输至第一PCM设备，进而传输至第二电子设备的功能，能够进一步降低实现的复杂性。

在某些实现方式中，所述将所述通话音频下行数据向所述第二电子设备传输，包括：通过对第一PCM设备文件进行读操作，从所述第一PCM设备中读取所述通话音频下行数据，并将所述通话音频下行数据向所述第二电子设备传输。通过对第一PCM设备文件的操作实现对第一PCM中的数据的读取，能够简化操作并具有较好的兼容性。

在某些实现方式中，所述与对端电子设备建立通话，包括：通过所述Modem与所述对端电子设备建立通话，所述将所述通话音频上行数据存储在第二PCM设备，且将所述第二PCM设备中的所述通话音频上行数据向所述对端电子设备传输，包括：通过打开第二PCM设备文件，打开所述第二PCM设备以及协同通话上行通路，接收所述第二电子设备发送的所述通话音频上行数据，通过对第二PCM设备文件进行写操作，将所述通话音频上行数据存储在所述第二PCM设备。通过对第二PCM设备文件的打开，打开第二PCM设备与协同通话上行通路，并通过对第二PCM设备文件的操作，将通话音频上行数据写入第二PCM设备，因为协同通话上行通路用于连接第二PCM设备与Modem，所以通话音频上行数据通过协同通话上行通路从第二PCM设备被传输至Modem，进而被传输至对端手机，能够进一步降低实现的复杂性。

在某些实现方式中，所述与对端电子设备建立通话，包括：通过所述Modem与所述对端电子设备建立通话。将所述通话音频上行数据和所述通话音频下行数据存储在第三PCM设备，包括：通过打开第三PCM设备文件，打开所述第三PCM设备以及通话录音IncallRecord通路，所述Incall Record通路用于连接所述第三PCM设备与所述Modem，从而能够进一步降低实现的复杂性。

在某些实现方式中，还包括：通过读取所述第三PCM设备文件，从所述第三PCM设备中获取所述通话音频上行数据和所述通话音频下行数据，录制所述通话音频下行数据和所述通话音频上行数据。可见第三PCM设备所以可以为后续的录制提供通话音频上行数据和通话音频下行数据，所以能够避免混音等步骤，有利于降低功耗。

在某些实现方式中，还包括：响应于通话录音结束或通话结束操作，通过关闭第三PCM设备文件，关闭所述第三PCM设备。通过PCM设备文件关闭相应的PCM设备，能够简化操作并具有较好的兼容性。

在某些实现方式中，还包括：响应于通话结束操作，通过关闭第一PCM设备文件，关闭所述第一PCM设备，并通过关闭第二PCM设备文件，关闭所述第二PCM设备。通过PCM设备文件关闭相应的PCM设备，能够简化操作并具有较好的兼容性。

在某些实现方式中，在所述将所述对端电子设备发送的通话音频下行数据存储在第一PCM设备，以及所述将所述第二电子设备发送的通话音频上行数据存储在第二PCM设备之前，还包括：通过查询音频场景USECASE与PCM设备的对应关系，确定所述多屏协同模式下的下行通话场景对应的PCM设备为所述第一PCM设备，所述多屏协同模式下的上行通话场景对应的PCM设备为所述第二PCM设备。可见，能够预先配置对应关系，并且通过配置修改对应关系，从而修改场景所使用的PCM设备，从而提高音频数据传输方法的灵活性。

在某些实现方式中，在所述响应于通话操作，与对端电子设备建立通话之前，还包括：显示协同窗口，所述协同窗口包括所述第二电子设备显示的拨号界面或来电界面，所述响应于通话操作，与对端电子设备建立通话，包括：响应于所述拨号界面或来电界面中的通话操作，与对端电子设备建立通话。基于协同窗口的操作实现通话，有利于获得较优的用户体验。

在某些实现方式中，在所述显示协同窗口之前，还包括：与所述第二电子设备之间通过近距离通信NFC、蓝牙或者有线方式，启动与所述第二电子设备的多屏协同模式。实现多屏协同模式的方式的多样性，能够进一步提升用户体验。

本申请的第二方面提供一种电子设备，包括：存储器以及至少一个处理器，所述存储器用于存储程序，所述处理器用于执行所述程序，以实现本申请的第一方面提供的通话音频数据的传输方法。

本申请的第三方面提供一种计算机存储介质，用于存储计算机程序，所述计算机程序被执行时，用于实现本申请的第一方面提供的通话音频数据的传输方法。

本申请的第四方面提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行本申请的一方面所述的通话音频数据的传输方法。

附图说明

图1a为多个电子设备进行多屏协同的场景示例图；

图1b为手机与笔记本电脑开启多屏协同的方式的示例图；

图1c为笔记本电脑进入多屏协同模式的示例图；

图1d为手机与笔记本电脑在多屏协同模式下的拨号界面示例图；

图1e为手机与笔记本电脑在多屏协同模式下的来电界面示例图；

图2为本申请实施例提供的一种电子设备的结构示例图；

图3a为本申请实施例提供的电子设备中运行的软件框架的示例图；

图3b为音频通路的示例图；

图3c为基于图3b所示的音频通路进行通话和紧急呼叫时音频数据传输的示例图；

图4为本申请实施例提供的多屏协同模式下一种传输通话音频数据的示例图；

图5a为本申请实施例提供的音频通路的示例图；

图5b为本申请实施例提供的一种通话音频数据的传输方法的流程图；

图6为本申请实施例提供的多屏协同模式下又一种传输通话音频数据的示例图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例涉及的多个，是指大于或等于两个。需要说明的是，在本申请实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

图1a为多设备协同的场景示例，其中，手机1与笔记本电脑2、个人数字助理（Personal Digital Assistant，PDA）3以及大屏4之间，分别可以进入多屏协同模式。

在多屏协同模式下，没有蜂窝通信能力的笔记本电脑2、PAD3以及大屏4，可以通过手机1的蜂窝通信能力，进行基于蜂窝网络的通信，包括但不限于：接听电话，拨打电话，基于蜂窝网络的视频通话。

以图1b为例，手机1在开启近场通信(Near Field Communication，NFC)功能的情况下，靠近开启NFC功能的笔记本电脑2的触控板后，手机1显示与笔记本电脑2的连接界面，在连接界面上点击“连接”控件后，如图1c所示，手机1与笔记本电脑2进入多屏协同模式。

如图1c所示，在多屏协同模式下，在笔记本电脑2上，显示手机1的协同窗口A，协同窗口A的显示内容与手机1当前显示的内容相同，以图1c为例，手机1当前显示一个桌面，笔记本电脑2的协同窗口A也显示相同的桌面。

在笔记本电脑2的协同窗口A上，通过鼠标点击或触控方式，可以进行与手机1上的操作相同的操作，例如，如图1c所示协同窗口A中显示手机1的某个桌面的情况下，在笔记本电脑2上，将鼠标的光标放置在协同窗口A中，并在笔记本电脑2的触控板上双指滑动，则可以在协同窗口A中切换手机的多个桌面。

又例如，可以在笔记本电脑2上，采用触控或鼠标方式点击协同窗口A中显示的电话应用程序的图标B，进入协同拨号界面C，如图1d所示，在笔记本电脑2上，采用触控或鼠标方式，在协同拨号界面C可以拨出电话。

如图1e所示，在多屏协同模式下，在手机1被呼叫时，笔记本电脑2的协同桌面A中显示协同来电界面D，采用触控或鼠标方式，在协同来电界面D上可以接听电话。

在上述多屏协同模式下，因为笔记本电脑2通过手机1的蜂窝通信网络拨打电话或接听电话，所以，在电话接通后，手机1与笔记本电脑2之间需要交互通话音频数据。

本申请实施例提供了一种音频数据的传输方法，目的在于解决多屏协同场景下，如何在进入多屏协同模式的设备间传输通话音频数据的问题。

本申请实施例应用于具有蜂窝通信功能的电子设备，在一些实施例中，电子设备可以是手机（如图2所示）、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机（Ultra-mobile Personal Computer，UMPC）、手持计算机、上网本、个人数字助理（PersonalDigital Assistant，PDA）、可穿戴电子设备、智能手表等设备。

如图2所示，手机可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，视频编解码器，数字信号处理器（digital signal processor，DSP），音频处理器（audio signal processor，ADSP）基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路（inter-integrated circuit，I2C）接口，集成电路内置音频（inter-integrated circuitsound，I2S）接口，脉冲编码调制（pulse code modulation，PCM）接口，通用异步收发传输器（universal asynchronous receiver/transmitter，UART）接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。

PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。

UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的功能。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本申请另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

图2所示的电子设备运行如图3a所示的软件框架，软件框架为分层架构，分层架构将软件分成若干层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。

为了便于说明，本申请实施例以安卓（Android）系统为例，对Android系统的手机1的软件结构进行说明。

具体的说，在一些实施例中，将Android系统分为五层，从上至下分别为应用程序层、应用程序框架层（也称：系统框架层）、系统库和安卓运行时、硬件抽象层（hardwareabstraction layer，HAL）和内核层。

应用程序层包括应用程序，与本申请实施例相关的应用程序包括通话应用程序。

通话应用程序具有：响应于用户的拨打电话操作或接听电话操作（例如，点击来电显示界面的接听键）进行通话的功能，以及，响应于用户的开启录音操作（例如，点击通话界面的录音键）进行通话录音的功能，以及，响应于用户的拨打紧急呼叫电话操作（例如，在紧急呼叫界面选择紧急联系人拨号）进行紧急呼叫的功能。

当用户基于手机1进行接听电话、或者拨打电话、或者通话录音、或者拨打紧急电话时，通话应用程序响应于用户的操作，产生对应的指令发送至应用程序框架层。

在某些实现方式中，应用程序层还可以包括协同模块，协同模块在手机1与笔记本电脑2进行多屏协同连接时启动，主要负责通话状态的监听和通话逻辑的控制。

应用程序框架层为应用程序层的应用提供应用编程接口（ApplicationProgramming Interface，API）和编程框架，包括各种组件和服务来支持开发者的安卓开发。应用程序框架层还包括一些预先定义的函数。如图3a所示，应用程序框架层可包括窗口管理器、内容提供器、视图系统、资源管理器、通知管理器、摄像头服务等。与本申请实施例相关的模块包括分布式移动感知开发平台（Distributed Mobile Sensing developmentplatform，DMSDP）以及电话管理器。

结合图1c-图1e所示的多屏协同的场景，DMSDP为笔记本电脑2的扬声器、麦克风等分配标识，使得笔记本电脑2的扬声器、麦克风作为手机1的虚拟设备。除此之外，DMSDP还用于触发音频数据的传输通路的开启和关闭，将在以下流程中详细说明。

电话管理器用于提供手机1的通话功能。例如通话状态的管理(包括接通，挂断等)。

具体的，电话管理器提供与通话有关的类，例如，音频服务类(Audio Service)。当用户操作手机1进行接听电话、或者拨打电话、或者通话录音、或者拨打紧急电话时，通话应用程序响应于用户的操作，产生对应的指令发送至应用程序框架层的音频服务类。

系统库和安卓运行时包括系统库和安卓运行时（Android Runtime）。系统库可以包括多个功能模块。安卓运行时负责安卓系统的调度和管理，具体包括核心库和虚拟机。

系统库可以包括多个功能模块。与本申请实施例相关的模块包括音频库(AudioLibraries)。电话管理器只是向通话应用程序提供访问核心库的桥梁，具体的功能实现放在音频库中完成。例如，音频库中具有与应用程序框架层的音频服务类相对应的音频服务类(Audio Service)。

在另一些实现方式中，协同模块可以不部署在应用程序层，而是部署在系统库中。

硬件抽象层HAL为位于操作系统内核与硬件电路之间的接口层。与本申请实施例相关的模块包括：Audio HAL。Audio HAL定义了由音频服务调用手机必须实现以确保音频硬件功能正常运行的标准接口，负责将Audio Flinger/Audio Policy Service真正地与硬件设备关联起来。

如图3a所示，Audio HAL中预先配置使用场景（USECASE）与脉冲编码调制（pulsecode modulation，PCM）设备标识的对应关系。USECASE为预先定义的一些音频场景，例如：record为普通录音场景，voice_call为语音通话场景，USECASE还具备上行和/或下行属性，例如record为上行和下行，即普通录音场景要获得上行和下行音频数据。USECASE与PCM设备标识的对应关系中，各个USECASE分别对应要实现该场景使用的PCM设备的标识。

通常PCM设备被认为是用于缓存PCM数据（如音频数据）的软件节点。PCM设备被抽象为PCM设备文件，即PCM设备文件表示PCM设备。Audio HAL可以对PCM设备文件进行创建、打开、或关闭操作，实现PCM设备的创建、开启或关闭，打开的PCM设备，可以缓存PCM数据，Audio HAL还可以从中读取PCM数据。

如图3a所示，Audio HAL中还包括虚拟Modem，虚拟Modem是写在Audio HAL中的一段程序，在该段程序运行时实现：协同通话时，对PCM设备以及通路的开启或关闭等操作，将在下面进行详细说明。

内核层是硬件和软件之间的层。PCM设备文件被保存在内核层中，此外内核层还至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动、ADSP驱动等。

可以理解的，图3a示出的应用程序框架层、系统库与运行时层包含的部件，并不构成对电子设备的具体限定。在实际应用中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。

在一种实现方式中，基于如图3a所示的软件框架以及手机的硬件1的结构，手机1的通话流程为：

当用户接听来电时，通话应用程序响应用户对手机1的接听来电操作（例如，点击来电显示界面的接听键等），生成开启通话指令，并调用电话管理器的音频服务类和音频库的音频服务类，将该开启通话指令下发至Audio HAL，再由Audio HAL下发至ADSP。ADSP收到该开启通话指令后，通过Modem接收通话对端手机发送的通话下行数据，并发送至扬声器进行播放，以及，获取麦克风采集的通话上行数据，并通过Modem发送至通话对端设备。

当用户拨打电话时，通话应用程序响应用户对手机1的拨打电话操作（例如，进入主界面的电话，选择相关联系人，点击进行拨号等），并在通话对端设备接通后生成开启通话指令。之后，通话应用程序调用电话管理器的音频服务类和音频库的音频服务类，将该开启通话指令下发至Audio HAL，再由Audio HAL下发至ADSP。ADSP收到该开启通话指令后，接收通话对端设备发送的通话下行数据，并发送至扬声器进行播放，以及，获取麦克风采集的通话上行数据，并发送至通话对端设备。

在一些场景下，ADSP还可以将通话下行数据发送至受话器进行播放，或者，经耳机接口发送至有线耳机进行播放，或者，经蓝牙发送至无线耳机进行播放。同时，ADSP获取的通话上行数据还可以是与手机1连接的无线耳机或者有线耳机采集的。本申请实施例对此不做任何限制。

ADSP是处理音频的数字信号处理器。

如图3b所示，PCM0、PCM1、……、PCM3为PCM设备，DAI0……DAI5为接口，耳机、扬声器等为音频设备。ADSP用于实现PCM设备与接口的连接。这里将连接PCM设备与音频设备的通路，称为音频通路。可以理解的是，音频通路包括ADSP中的连通部分以及接口。

假设PCM1用于缓存通话音频上行数据和通话音频下行数据。音频通路的一种示例为Incall Record通路，Incall Record通路为连接PCM1与麦克风以及Modem的音频通路。假设PCM0用于缓存紧急呼叫数据（即一段固定音频数据），Incall Music通路为连接PCM0与Modem的音频通路。

可以理解的是，因为ADSP中的音频通路用于与PCM设备交互数据，并且，接口和音频设备在电子设备启动后，通常处于打开状态，所以，通过PCM设备文件打开PCM设备的同时，音频通路也被打开。

基于图3a以及图3b，手机1实现通话录音功能的流程如图3c所示：

手机1的ADSP11通过Modem12接收对端手机3发送的通话音频下行数据，并发送至扬声器14进行播放，以及，获取麦克风13采集的通话音频上行数据，并通过Modem12发送至对端手机3。对端手机3中，ADSP31与Modem32交互通话音频数据。

手机1中的通话应用程序15显示的来电界面中的录音控件被点击后，通话应用程序15生成开启录音指令，并调用电话管理器中的音频服务类和音频库中的音频服务类（图3c中统称为音频服务类16），将该开启录音指令下发至Audio HAL17。

Audio HAL17确定电话录音指令对应的USECASE为USECASE1（上行和下行），并通过USECASE1与PCM1的对应关系，确定获取通话音频的PCM设备为PCM1。

Audio HAL17通过打开PCM1设备文件，打开PCM1以及Incall Record通路，IncallRecord通路将通话音频上行数据和通话音频下行数据传输至PCM1缓存，Audio HAL17通过对PCM1设备文件读取（read）的操作，从PCM1中获取通话音频上行数据和通话音频下行数据。Audio HAL17将获取的通话音频上行数据和通话音频下行数据，经由音频库中的音频服务类和电话管理器中的音频服务类（图3c中统称为音频服务类16）向通话应用程序15传输，通话应用程序15按照预设格式存储通话音频上行数据和通话音频下行数据，完成通话录音功能。

图3c中，还示出了基于图3a以及图3b，手机1实现紧急呼叫（紧急呼叫是指向指定手机号传输固定的音频，以提醒指定手机号的用户代替手机1的用户报警）的流程：

当用户拨打紧急呼叫时，通话应用程序15响应用户的拨打紧急呼叫操作（例如，在锁屏界面点击紧急呼叫，点击个人紧急信息，选择紧急联系人拨号等），将紧急呼叫数据（紧急呼叫数据为一段固定音频数据）写入电话管理器的音频服务类，再由电话管理器的音频服务类写入音频库的音频服务类，再由音频库的音频服务类（图3c中统称为音频服务类16）写入Audio HAL17。Audio HAL17通过打开PCM0设备文件，打开PCM0以及Incall Music通路，并将紧急呼叫数据写入PCM0。Incall Music通路将紧急呼叫数据传输至Modem12，Modem12将紧急呼叫数据传输至对端手机，使得作为紧急联系人的对端手机的用户，帮手机1的用户拨打求救电话。

为了满足多屏协同场景下，手机1与笔记本电脑2之间传输通话音频数据的需求，在某些实现方式中，手机1中的Audio HAL17复用PCM设备以及音频通路，与笔记本电脑2之间传输通话音频数据。多屏协同场景下被复用是指，原本有要实现的数据传输功能，但在多屏协同场景下，还承担通话音频数据传输的功能。

以图4为例，复用PCM1，向笔记本电脑2传输通话音频下行数据：协同模块18和DMSDP模块19监测到多屏协同下的通话，向Audio HAL17下发协同通话指令，Audio HAL17确定USECASE为音频通话下行场景，对应PCM1，Audio HAL17打开PCM1，PCM1中缓存通过IncallRecord通路传输的通话音频下行数据，而不再传输通话音频上行数据，Audio HAL17将PCM1中的通话音频下行数据，通过无线通信模块160向笔记本电脑2传输。

在此情况下，如果用户在手机1开启通话录音功能，如图3c所示，Audio HAL17需要从PCM1中获取下行数据和上行数据，而如图4所示，协同通话场景下PCM1中仅缓存下行数据，可见，录音功能与协同通话功能发生冲突。

针对冲突的一种处理方式为：在Audio HAL17将上行数据与下行数据进行混音处理后，发送至通话应用程序15。可以理解的是，针对冲突的处理，会增加手机1的功耗。

还以图4为例，复用PCM0，接收笔记本电脑2传输的通话音频上行数据：即AudioHAL17经由无线通信模块160接收笔记本电脑2传输的上行数据后，将上行数据缓存至PCM0，Incall Music通路将上行数据传输至Modem12，Modem12将上行数据向对端手机3传输。

可以理解的是，在协同通话场景下，如果用户开启紧急通话功能，两种功能导致PCM0缓存的数据发生冲突。

可见，多屏协同模式下，复用PCM设备以及音频通路，实现与协同设备交互通话音频数据，在某些情况下，会导致冲突。

为了解决上述冲突，本申请实施例提供以下改进方式：

在Audio HAL除了配置音频通话USECASE与PCM1（即第三PCM设备）之间的对应关系，之外，还配置以下对应关系：

多屏协同通话音频下行数据传输场景，简称为USECASE2，与PCM2（即第一PCM设备）的对应关系。

多屏协同通话音频上行数据传输场景，简称为USECASE3，与PCM3（即第二PCM设备）的对应关系。

其中，PCM2与PCM3为不同的PCM设备。PCM2以及PCM3，均为与PCM1不同的PCM设备。结合上述通话录音的流程可知，PCM1用于获取通话音频上行数据和通话音频下行数据。而PCM2用于获取通话音频下行数据，PCM3用于获取通话音频上行数据。

如图5a所示，配置用于传输通话音频下行数据的通路，简称为协同通话下行通路，以及用于传输通话音频上行数据的通路，简称为协同通话上行通路。

可以理解的是，协同通话下行通路连接PCM2与Modem。协同通话上行通路连接PCM3与Modem。

可以理解的是，在某些实现方式中，笔记本电脑2的内置或外接扬声器和麦克风，均被DMSDP配置为手机1的虚拟设备，将笔记本电脑2的内置或外接扬声器称为虚拟扬声器，将笔记本电脑2的内置或外接麦克风称为虚拟麦克风。

需要说明的是，USECASE并非必须配置的参数，也就是说，可以不配置USECASE，而配置协同通话与PCM2以及PCM3的对应关系。

可以理解的是，可以使用acdb files和XML配置文件等，配置上述对应关系。

基于上述配置，可以实现多屏协同场景下，进入多屏协同模式的设备之间音频数据的传输，多屏协同的场景的示例如图1a所示，具有蜂窝通信能力的手机1可以与图1a中所示的2、3、以及4进入多屏协同模式。

以图1b-图1c所示，手机1与笔记本电脑2通过NFC方式进入多屏协同模式。可以理解的是，NFC方式仅为进入多屏协同模式的一种示例，还可以通过蓝牙、有线连接等方式，进入多屏协同模式，这里不再赘述。

在多屏协同模式下，可以通过操作手机1的界面或者笔记本电脑2的协同窗口显示的界面，进入拨打电话的界面，如图1d所示的界面C，或者，有来电的情况下，在手机1以及笔记本电脑2上均显示来电提醒界面，如图1e所示的界面D。

在用户在笔记本电脑2上播出电话，或者，在笔记本电脑2上接听电话后，触发执行图5b所示的流程，包括以下步骤：

S01、通话应用程序向Audio HAL传输通话操作通知。

通话应用程序响应于拨打或接听电话的操作，向Audio HAL传输通话操作通知：

在某些实现方式中，通话应用程序显示如图1d所示的拨号界面，用户在拨号界面拨打，通话应用程序响应于拨打电话的操作，向Audio HAL传输指示拨打电话操作的通知。

在另一些实现方式中，用户在如图1e所示的来电提醒界面上点击接听控件，通话应用程序响应于接听控件的点击操作，从拨号界面切换至通话界面，并向Audio HAL传输接听电话的通知。

可以理解的是，如图6所示，通话应用程序15通过电话管理器中的音频服务类和音频库中的音频服务类（图6中统称为音频服务类16），向Audio HAL17传输通话操作通知。

S02、Audio HAL响应于通话操作通知，向ADSP下发通话建立指令。

在某些实现方式中，Audio HAL通过如图3a中所示的ADSP驱动，向ADSP下发通话建立指令。

S03、ADSP与Modem建立通话下行和上行通路。

可以理解的是，结合图6所示，手机1中ADSP11、Modem12、对端手机的ADSP31以及Modem32依据蜂窝通信协议，实现手机1与对端手机3之间建立通话流程，由此，ADSP11与Modem12之间建立通话下行和上行通路。

可以理解的是，在建立通话下行和上行通路后，如果已经产生通话音频数据，通路上即可传输通话音频数据。

S04、协同模块向DMSDP下发协同通话的指令。

结合图6所示，协同模块18在开启多屏协同模式后，如果在开启多屏协同模式下监测到通话状态，则向DMSDP19下发协同通话的指令。

S05、DMSDP接收到协同通话的指令后，如果监测到通话状态，向Audio HAL下发指示USECASE2以及USECASE3的指令。

在某些实现方式中，结合图6所示，指示USECASE2以及USECASE3的指令，可以携带在图6所示的DMSDP19向Audio HAL17下发的协同通话的指令中。

可以理解的是，在某些实现方式中，在不配置USECASE2以及USECASE3的情况下，DMSDP16可以向Audio HAL17下发指示调用PCM2以及PCM3的指令，指示调用PCM2以及PCM3的指令可以携带在图6所示的DMSDP19向Audio HAL17下发的协同通话的指令中。

DMSDP监测通话状态，作为协同模块的监测结果的补充和验证，能够保证监测结果的准确性。

S06、Audio HAL依据USECASE2以及上述预先配置的对应关系，打开PCM2。

在某些实现方式中，虚拟Modem通过打开（open）PCM2设备文件，实现打开PCM2的目的。在打开PCM2之后，如图5a所示，连接PCM2与Modem的协同通话下行通路被打开。

在某些实现方式中，S06具体由Audio HAL中的虚拟Modem执行。

S07、Audio HAL依据USECASE3以及上述预先配置的对应关系，打开PCM3。

可以理解的是，S06与S07的顺序不做限定。

在某些实现方式中，通过打开（open）PCM3设备文件，实现打开PCM3的目的。在打开PCM3之后，连接PCM3与Modem的协同通话上行通路被打开。

在某些实现方式中，S07具体由Audio HAL中的虚拟Modem执行。

在不配置USECASE2以及USECASE3的情况下，Audio HAL依据调用PCM2以及PCM3的指令，打开PCM2设备文件以及PCM3设备文件，以打开PCM2、PCM3、协同通话下行通路和协同通话上行通路。

因为S03中，Modem12与ADSP11之间已建立通话通路，所以，如图6所示，打开PCM2之后，PCM2缓存Modem12传输至ADSP11的通话音频下行数据。

S08、Audio HAL从PCM2中读取通话音频下行数据。

在某些实现方式中， Audio HAL通过对PCM2设备的读（read）操作，实现对PCM2中的通话音频下行数据的读取。

在某些实现方式中，S08具体由Audio HAL中的虚拟Modem执行。

S09、Audio HAL将通话音频下行数据传输至无线通信模块。

结合图6所示，Audio HAL调用无线通信模块160，将通话音频下行数据向笔记本电脑2传输，笔记本电脑2的扬声器播放通话音频下行数据。

在某些实现方式中，S09具体由Audio HAL中的虚拟Modem执行。在另一些实现方式中，S09具体由Audio HAL中的音频硬件管理模块执行。

S10、Audio HAL从无线通信模块接收通话音频上行数据。

可以理解的是，缓存笔记本电脑2采集用户的语音（即通话音频上行数据），并传输至无线通信模块160，Audio HAL17通过调用无线通信模块接收通话音频上行数据。

S11、Audio HAL将通话音频上行数据，缓存至PCM3。

在某些实现方式中，Audio HAL通过对PCM3设备文件的写（write）操作，实现向PCM3中缓存数据的目的。

可以理解的是，因为S03中，Modem与ADSP之间已建立通话通路，所以，如图6所示，打开PCM3之后，PCM3中缓存的通话音频上行数据被传输至ADSP11，进一步被传输至Modem12，再由Modem12传输至对端手机3。

在某些实现方式中，S10-S11具体由Audio HAL中的虚拟Modem执行。在另一些实现方式中，S10-S11具体由Audio HAL中的音频硬件管理模块执行。

在通话过程中，如果用户通过在通话界面上点击录音控件，开启通话录音功能，则执行S12-S17。

S12、通话应用程序向Audio HAL下发录音操作通知。

在某些实现方式中，结合图6所示，用户在笔记本电脑2的协同通话界面E中点击录音控件F，则笔记本电脑2经由手机1的无线通信模块160向协同模块18传输录音操作通知，协同模块18向手机1的通话应用程序15传输录音操作通知，通话应用程序15通过音频服务类16，向Audio HAL17下发录音操作通知，即如图5b所示。在另一些实现方式中，结合图6所示，用户在笔记本电脑2的协同通话界面E中点击录音控件F，则笔记本电脑2经由手机1的无线通信模块160向协同模块18传输录音操作通知，手机1的协同模块18经由DMSDP19，向Audio HAL17下发录音操作通知（图5b中未画出）。

S13、Audio HAL确定USECASE1。

可以理解的是，Audio HAL依据录音操作通知以及预先配置的对应关系，确定USECASE为USECASE1。

S14、Audio HAL打开USECASE1对应的PCM1。

可以理解的是，如图6所示，打开PCM1后，通话音频上行数据和通话音频下行数据，均通过图5a所示的Incall Record通路，缓存至PCM1。

S15、Audio HAL从PCM1中读取通话音频上行数据和通话音频下行数据。

在某些实现方式中，Audio HAL通过对PCM1设备文件的读（read）操作，实现对PCM1中的通话音频上行数据和通话音频下行数据的读取。

S16、Audio HAL向通话应用程序传输通话音频上行数据和通话音频下行数据。

结合图6所示，Audio HAL17将通话音频上行数据和通话音频下行数据，经由音频库中的音频服务类和电话管理器中的音频服务类（图6中统称为音频服务类16），向通话应用程序15传输通话音频上行数据和通话音频下行数据。

S17、Audio HAL在通话录音结束或通话结束后，关闭PCM1。

在某些实现方式中，结合图6所示，用户在笔记本电脑2的协同通话界面E中点击（被按下的）录音控件F以关闭录音功能，或者，用户点击协同通话界面E中的通话结束控件G以结束通话，则笔记本电脑2经由无线通信模块160向手机1的协同模块18传输录音结束通知或者通话结束通知，手机1的协同模块18向手机1的通话应用程序15传输录音操作通知，通话应用程序15通过音频服务类16，向Audio HAL17下发通话录音结束或通话结束的通知。

在另一种实现方式中，用户在笔记本电脑2的协同通话界面E中点击（被按下的）录音控件F，关闭录音功能，或者，用户点击协同通话界面E中的通话结束控件G以结束通话，则笔记本电脑2经由无线通信模块160向手机1的协同模块18传输录音结束通知或者通话结束通知，协同模块18经由DMSDP19，向Audio HAL17下发通话录音结束或通话结束的通知。

在又一种实现方式中，如图1c-图1e所示，因为笔记本电脑2中显示的协同界面，例如A、C以及D，又例如图6中E所示，与手机1中显示的界面相同，所以，用户还可以在手机1中的通话界面（与图6中的通话界面E相同）中，点击（被按下的）录音控件F以关闭录音功能，或者，点击通话结束控件G以结束通话，通话应用程序15响应于通话录音结束操作或者通话结束操作，向Audio HAL17传输通话录音结束或通话结束的通知。

可以理解的是，S12-S17为可选步骤，在通话过程中不开启通话录音功能的情况下不执行。

在某些实现方式中，S12-S17的执行主体为Audio HAL中的音频硬件管理模块。

S18、在DMSDP监测到通话结束后，向Audio HAL下发通话结束通知。

在某些实现方式中，在S18之前，协同模块监测到通话结束后，通知DMSDP，DMSDP在接收到通知并监测到通话结束后，向Audio HAL下发通话结束通知。

可以理解的是，协同模块监测到通话结束的方式，可以参见S17中，协同模块获取通话结束通知的方式。

S19、Audio HAL关闭PCM2。

在某些实现方式中，通过关闭（close）PCM2文件，关闭PCM2，PCM2关闭后，协同通话下行通路无法向PCM2传输数据，所以相当于关闭了协同通话下行通路。

S20、Audio HAL关闭PCM3。

在某些实现方式中，通过关闭PCM3文件，关闭PCM3以及协同通话上行通路。

从图5b和图6可以看出，在多屏协同模式下，不再复用已被某些功能占用的PCM设备以及通路，传输协同设备之间的通话音频数据，所以能够避免PCM设备以及通路复用而可能导致的冲突，从而进一步避免因避免冲突而导致的混音、转发等操作，因此能够减少电子设备的功耗。

可以理解的是，图6中，并未画出PCM0，以及紧急通话的场景，但在协同通话场景下，因为没有占用PCM0，所以紧急通话的流程，可以参见图3c。

上文详细介绍了本申请实施例提供的通话音频数据的传输方法的示例。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分为各个功能模块，例如ADSP、Modem等，也可以将两个或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例提供的电子设备，用于执行上述通话音频数据的传输方法，因此可以达到与上述实现方法相同的效果。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任一实施例的通话音频数据的传输方法。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的通话音频数据的传输方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的通话音频数据的传输方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

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

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

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

Claims (8)

1.一种通话音频数据的传输方法，其特征在于，应用第一电子设备，所述第一电子设备包括第一PCM设备，第二PCM设备和第三PCM设备，所述第一PCM设备，所述第二PCM设备和所述第三PCM设备用于缓存PCM音频数据，所述方法包括：

响应于通话操作，通过调制解调器Modem与对端电子设备建立通话，其中，所述第一电子设备与第二电子设备处于多屏协同模式；

接收所述对端电子设备发送的通话音频下行数据；

通过打开第一PCM设备文件，打开所述第一PCM设备以及协同通话下行通路后，所述第一PCM设备存储所述通话音频下行数据，所述协同通话下行通路用于连接所述第一PCM设备与所述Modem；

通过对所述第一PCM设备文件进行读操作，从所述第一PCM设备中读取所述通话音频下行数据，并将所述通话音频下行数据向所述第二电子设备传输；

接收所述第二电子设备发送的通话音频上行数据；

通过打开第二PCM设备文件，打开所述第二PCM设备以及协同通话上行通路后，通过对所述第二PCM设备文件进行写操作，将所述通话音频上行数据存储在所述第二PCM设备中，所述协同通话上行通路用于连接所述第二PCM设备与所述Modem；

将所述第二PCM设备中的所述通话音频上行数据向所述对端电子设备传输；

响应于通话录音操作，通过打开第三PCM设备文件，打开所述第三PCM设备以及通话录音Incall Record通路，所述Incall Record通路用于连接所述第三PCM设备与所述Modem；

通过读取所述第三PCM设备文件，从所述第三PCM设备中获取所述通话音频上行数据和所述通话音频下行数据；

录制所述通话音频下行数据和所述通话音频上行数据。

2.根据权利要求1所述的方法，其特征在于，还包括：

响应于通话录音结束或通话结束操作，通过关闭第三PCM设备文件，关闭所述第三PCM设备。

3.根据权利要求1所述的方法，其特征在于，还包括：

响应于通话结束操作，通过关闭第一PCM设备文件，关闭所述第一PCM设备，并通过关闭第二PCM设备文件，关闭所述第二PCM设备。

4.根据权利要求1所述的方法，其特征在于，在所述第一PCM设备存储所述通话音频下行数据，以及所述将所述通话音频上行数据存储在所述第二PCM设备之前，还包括：

通过查询音频场景USECASE与PCM设备的对应关系，确定所述多屏协同模式下的下行通话场景对应的PCM设备为所述第一PCM设备，所述多屏协同模式下的上行通话场景对应的PCM设备为所述第二PCM设备。

5.根据权利要求1所述的方法，其特征在于，在所述与对端电子设备建立通话之前，还包括：

显示协同窗口，所述协同窗口包括所述第二电子设备显示的拨号界面或来电界面；

所述响应于通话操作，与对端电子设备建立通话，包括：

响应于所述拨号界面或来电界面中的通话操作，与对端电子设备建立通话。

6.根据权利要求5所述的方法，其特征在于，在所述显示协同窗口之前，还包括：

与所述第二电子设备之间通过近距离通信NFC、蓝牙或者有线方式，启动与所述第二电子设备的多屏协同模式。

7.一种电子设备，其特征在于，包括：

存储器以及至少一个处理器；

所述存储器用于存储程序；

所述处理器用于执行所述程序，以实现权利要求1-6任一项所述的通话音频数据的传输方法。

8.一种计算机存储介质，用于存储计算机程序，所述计算机程序被执行时，用于实现权利要求1-6任一项所述的通话音频数据的传输方法。