投屏方法、设备及存储介质与流程

1.本技术涉及投屏技术领域，尤其涉及一种投屏方法、设备及存储介质。


背景技术：

2.随着终端技术的发展，越来越多的终端具备投屏功能，例如在家庭、工作、教学、游戏竞技场景下，终端通过将当前显示的画面投射到大屏上，从而可以大大方便人们观看画面内容。
3.对于投屏发送端，即发送投屏信息的终端是个人计算机（personal computer，pc设备）的投屏场景，目前需要借助安装在pc设备上的投屏应用来实现将pc设备中播放的音视频内容投屏到投屏接收端，如电视等大屏幕设备（后续称为大屏设备）上。
4.虽然pc设备可以借助投屏应用实现投屏功能，但是却存在着一些不容忽视的问题，比如pc设备的音频状态可能会与用户在投屏前，或者投屏中修改的状态不一致。


技术实现要素：

5.为了解决上述技术问题，本技术提供一种投屏方法、设备及存储介质，旨在实现投屏场景中，pc设备的音频状态能够与用户设置的一致。
6.第一方面，本技术提供一种投屏方法，应用于投屏发送端，所述投屏发送端安装有投屏应用，所述方法包括：在所述投屏发送端的显示界面中显示音频状态切换控件和音量条控件；在所述投屏发送端播放以所述音量条控件对应的音量值播放音频数据时，当接收到对所述音频状态切换控件的点击操作后，所述投屏发送端响应于所述点击操作停止出声；在所述投屏发送端与投屏接收端建立投屏连接后，由所述投屏接收端播放所述音频数据；在接收到将声音输出设备由所述投屏接收端切换为所述投屏发送端的点击操作后，所述投屏发送端响应于所述点击操作，停止向所述投屏接收端发送所述音频数据，并保持不出声。由此，在投屏过程中，当声音输出设备切换为投屏发送端时，投屏发送端是否出声取决于音频状态切换控件当前的状态，从而保证了投屏场景中，投屏发送端的是否出声能够与用户期望的一致。
7.根据第一方面，在所述停止向所述投屏接收端发送所述音频数据，并保持不出声之后，所述方法还包括：在接收到对所述音频状态切换控件的点击操作后，所述投屏发送端响应于所述点击操作，以所述音量条控件对应的音量值播放音频数据。
8.根据第一方面，或者以上第一方面的任意一种实现方式，在接收到对所述音频状态切换控件的点击操作后，所述投屏发送端响应于所述点击操作，以所述音量条控件对应的音量值播放音频数据之后，所述方法还包括：在接收到对所述音频状态切换控件的点击操作后，所述投屏发送端响应于所述点击操作停止出声。
9.根据第一方面，或者以上第一方面的任意一种实现方式，在所述投屏发送端与投屏接收端建立投屏连接后，由所述投屏接收端播放所述音频数据之后，所述方法还包括：在接收到断开所述投屏发送端与所述投屏接收端之间的投屏连接后，所述投屏发送端响应于
所述点击操作，停止向所述投屏接收端发送所述音频数据，并保持不出声。
10.根据第一方面，或者以上第一方面的任意一种实现方式，在所述投屏发送端与投屏接收端建立投屏连接后，由所述投屏接收端播放所述音频数据之后，所述方法还包括：在接收到对所述音量条控件的点击操作后，由所述投屏接收端根据调整后的音量值播放所述音频数据。
11.第二方面，本技术提供一种投屏方法，应用于投屏发送端，所述投屏发送端安装有投屏应用，所述方法包括：在接收到投屏连接请求后，获取所述投屏发送端的初始音频状态，并记录到音频状态表，所述初始音频状态为静音状态或非静音状态；确定用户选择的声音输出设备；在所述声音输出设备为所述投屏发送端时，将所述投屏发送端的音频状态设置为所述初始音频状态；在所述声音输出设备为投屏接收端时，将所述投屏发送端设置为静音状态，将投屏信息中的音频数据发送至所述投屏接收端。
12.示例性的，所述投屏发送端为pc设备。
13.由此，本技术提供的投屏方案，通过在投屏场景中通过获取投屏发送端在建立投屏连接前的音频状态，并将获取到的音频状态作为投屏发送端的初始音频状态记录到音频状态表，这样在确定用户选择的声音输出设备为投屏发送端时，直接将投屏发送端的音频状态设置为音频状态表中记录的初始音频状态，从而使得投屏场景中，在声音切回到投屏发送端时，投屏发送端的音频状态能够与用户期望的音频状态一致，进而大大提升了用户体验。
14.根据第二方面，在所述获取所述投屏发送端的初始音频状态，并记录到音频状态表之后，所述方法还包括：调用音频状态监控模块，监控用户对所述投屏发送端的音频状态切换控件的点击操作，在所述音频状态切换控件对应的音频状态为所述静音状态时，所述音频状态切换控件被点击后，所述音频状态从所述静音状态切换为所述非静音状态，在所述音频状态切换控件对应的音频状态为所述非静音状态时，所述音频状态切换控件被点击后，所述音频状态从所述非静音状态切换为所述静音状态；在监控到用户对所述音频状态切换控件的点击操作后，根据切换后的所述音频状态更新所述音频状态表中记录的所述初始音频状态。
15.由此，本技术提供的投屏方案，通过在投屏过程中启动音频状态监控模块持续监控投屏发送端的音频状态，并在音频状态发生改变时更新音频状态表中记录的初始音频状态，使得音频状态表中记录的初始音频状态能够根据用户的实际操作进行变更，进而保证断开投屏或者将声音输出设备变更为投屏发送端时根据音频状态表中记录的初始音频状态设置的音频状态与用户实际想要设置的音频状态相一致。这样就可以解决现有方案中投屏前或者投屏中用户手动修改投屏发送端为静音状态，断开投屏或由大屏设备出声切换为投屏发送端出声后，投屏发送端的音频状态能够与用户设置的一致处于静音状态而不是直接出声。
16.根据第二方面，或者以上第二方面的任意一种实现方式，在所述将投屏信息中的音频数据发送至所述投屏接收端之后，所述方法还包括：在用户将声音输出设备从所述投屏接收端变更为所述投屏发送端后，读取所述音频状态表中记录的所述初始音频状态；将所述投屏发送端的音频状态设置为所述初始音频状态。
17.由此，本技术提供的投屏方案，通过根据音频状态表中记录的初始音频状态来设
置投屏发送端的音频状态，从而使得声音输出设备从投屏接收端变更为投屏发送端后，投屏发送端的音频状态能够与用户设置的状态相一致，进一步提升用户体验。
18.根据第二方面，或者以上第二方面的任意一种实现方式，在接收到投屏断开请求后，读取所述音频状态表中记录的所述初始音频状态；将所述投屏发送端的音频状态设置为所述初始音频状态。
19.由此，本技术提供的投屏方案，通过根据音频状态表中记录的初始音频状态来设置投屏发送端的音频状态，从而使得投屏断开后，投屏发送端的音频状态能够与用户设置的状态相一致，进一步提升用户体验。
20.根据第二方面，或者以上第二方面的任意一种实现方式，在断开与所述投屏接收端的连接之后，所述方法还包括：关闭所述音频状态监控模块。
21.由此，本技术提供的投屏方案，在投屏结束后停止继续监控音频状态的变化，从而有效避免了对投屏发送端资源的占用和浪费。
22.根据第二方面，或者以上第二方面的任意一种实现方式，所述投屏应用包括投屏管理模块、音频管理模块和传输模块，所述投屏管理模块与所述音频管理模块进行数据交互，所述音频管理模块与所述传输模块进行数据交互；所述将所述投屏发送端的音频状态设置为所述初始音频状态，包括：由所述音频管理模块将所述投屏发送端的音频状态设置为所述初始音频状态。
23.由此，本技术提供的投屏方案，在投屏过程中通过由音频管理模块来设置投屏发送端的音频状态，这样不管投屏应用采用的是哪种协议，音频管理模块只需采用统一的方式进行设置即可，大大减小了开发工作量和维护难度。
24.根据第二方面，或者以上第二方面的任意一种实现方式，所述投屏应用包括投屏管理模块、音频管理模块和传输模块，所述投屏管理模块与所述音频管理模块进行数据交互，所述音频管理模块与所述传输模块进行数据交互，所述音频状态表由所述音频管理模块管理；所述将所述投屏发送端的音频状态设置为所述初始音频状态，包括：所述传输模块向所述音频管理模块发送初始音频状态查询请求；所述音频管理模块根据所述初始音频查询请求，将所述音频状态表中记录的所述初始音频状态发送给所述传输模块；所述传输模块将所述投屏发送端的音频状态设置为所述初始音频状态。
25.由此，本技术提供的投屏方案，在投屏过程中通过由传输模块来设置投屏发送端的音频状态，这样采用不同协议的投屏应用能够根据实际需求个性化设置，使得本技术提供的投屏方案更加多元化。
26.根据第二方面，或者以上第二方面的任意一种实现方式，所述将投屏信息中的音频数据发送至所述投屏接收端，包括：确定所述音频数据对应的协议类型；根据所述协议类型确定所述音频数据的目标编码方式；根据所述目标编码方式对所述音频数据进行编码，得到音频数据包；将所述音频数据包发送至所述投屏接收端。这样，通过音频数据对应的协议类型对应的编码方式对音频数据进行编码，从而保证了对应不同协议类型的音频数据能够采用不同的编码方式进行编码，使得本技术提供的投屏方案能够适应于采用不同协议类型的协议的投屏应用。
27.根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：在将所述音频数据包发送至所述投屏接收端时，将所述协议类型发送至所述投屏接收端。这样，投
屏接收端就可以知道需要采用哪种解码方式对音频数据包解码，从而保证解码结果的准确性。
28.根据第二方面，或者以上第二方面的任意一种实现方式，所述根据所述协议类型确定所述音频数据的目标编码方式，包括：在编解码映射关系表中查找所述协议类型对应的编码方式，所述编解码映射关系表由所述投屏发送端和所述投屏接收端协商确定；将查找到的编码方式确定为所述目标编码方式。
29.由此，本技术提供的投屏方案，确定协议类型对应的编码方式/解码方式的编解码映射关系表由投屏发送端和投屏接收端预先协商确定，这样投屏发送端和投屏接收端之间不直接传输编码方式，从而能够避免二者之间传输的内容被拦截后解码出音频数据，进而保证了传输内容的安全性。
30.第三方面，本技术提供了一种电子设备，所述电子设备为投屏发送终端，包括处理器以及存储器；其中，所述存储器和所述处理器耦合，所述存储器存储有程序指令；当所述程序指令由所述处理器执行时，使得所述电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令，或者执行第二方面，或者以上第二方面的任意一种实现方式中的方法的指令。
31.第四方面，本技术提供了一种计算机可读介质，用于存储计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令，或者执行第二方面，或者以上第二方面的任意一种实现方式中的方法的指令。
32.第五方面，本技术提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当其在电子设备上运行时，使得所述电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令，或者执行第二方面，或者以上第二方面的任意一种实现方式中的方法的指令。
33.第六方面，本技术提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令，或者执行第二方面，或者以上第二方面的任意一种实现方式中的方法的指令，以控制接收管脚接收信号，以控制发送管脚发送信号。
34.第七方面，本技术提供一种投屏系统系统，该系统包括投屏发送端和投屏接收端。
35.示例性的，所述投屏发送端为上述第三方面涉及的电子设备。
36.示例性的，所述投屏接收端为电视，或其他能够接收所述投屏发送端发送的投屏信息，并投放的设备。
附图说明
37.图1是示例性示出的本技术实施例提供的投屏方法的流程示意图；图2是示例性示出的投屏发送端主页面的示意图；图3是示例性示出的投屏应用发起投屏连接的示意图之一；图4是示例性示出的投屏应用发起投屏连接的示意图之二；图5是示例性示出的选择投屏接收端的界面示意图；图6是示例性示出的与选择的投屏接收端建立连接的界面示意图；
图7是示例性示出的投屏连接成功后投屏应用的界面示意图；图8是示例性示出的投屏连接成功后投屏发起端和投屏接收端的界面示意图；图9是示例性示出的用户调整投屏发送端为静音的示意图之一；图10是示例性是出的用户调整投屏发送端为静音的示意图之二；图11是示例性示出的用户调整投屏发送端为静音的示意图之三；图12是示例性示出的切换本机为声音输出设备时的示意图；图13是示例性示出的切换本机为声音输出设备后的示意图；图14是示例性示出的切换本机为声音输出设备后投屏发送端和投屏接收端声音变化的示意图之一；图15是示例性示出的切换本机为声音输出设备后投屏发送端和投屏接收端声音变化的示意图之二；图16是示例性示出的断开投屏后投屏发送端和投屏接收端声音变化的示意图之一；图17是示例性示出的断开投屏后投屏发送端和投屏接收端声音变化的示意图之二；图18是示例性示出的由上层的音频管理模块设置投屏发送端音频状态时调用的方法示意图；图19是示例性示出的由上层的音频管理模块设置投屏发送端音频状态的示意图之一；图20是示例性示出的由上层的音频管理模块设置投屏发送端音频状态的示意图之二；图21是示例性示出的由上层的音频管理模块设置投屏发送端音频状态的示意图之三；图22是示例性示出的由下层的传输模块设置投屏发送端音频状态时调用的方法示意图；图23是示例性示出的由下层的传输模块设置投屏发送端音频状态的示意图之一；图24是示例性示出的由下层的传输模块设置投屏发送端音频状态的示意图之二；图25是示例性示出的由下层的传输模块设置投屏发送端音频状态的示意图之三。
具体实施方式
38.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
39.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。
40.本技术实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
41.在本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
42.在本技术实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
43.在对本技术实施例的技术方案说明之前，首先对本技术实施例提供的技术方案适用于的电子设备进行说明。
44.具体的说，本实施例提供的技术方案是应用于投屏发送端的，并且投屏发送端是安装有投屏应用的pc设备（下文称为pc机）。
45.示例性的，在本实施例中，上述所说的pc机可以是台式机，也可以是笔记本电脑。
46.此外，需要说明的是，在本实施例中，接收投屏发送端发送的投屏内容，例如视频数据、图像数据、音频数据的投屏接收端可以是电视、显示屏等大屏设备。
47.下面对本技术实施例提供的技术方案的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
48.示例性的，参见图1，本技术实施例的具体实现步骤包括：步骤101，在接收到投屏连接请求后，获取所述投屏发送端的初始音频状态，并记录到音频状态表。
49.示例性的，在实际应用中，投屏应用例如可以包括投屏管理模块、音频管理模块和传输模块。
50.示例性的，投屏管理模块与音频管理模块进行数据交互，音频管理模块与传输模块进行数据交互。
51.具体到本实施例中，投屏场景中涉及的投屏连接请求、投屏断开请求、声音输出设备切换请求均是由投屏管理模块监控的。
52.进一步地，上述所说的投屏发送端的初始音频状态则是由音频管理模块获取并管理的。
53.进一步地，上述所说的传输模块则是用于将投屏发送端的投屏信息系传输给投屏接收端的。
54.示例性的，在一些实现场景中，投屏信息可以是音频数据、视频数据、图像数据中的任意一种或几种，本实施例对此不做限制。
55.此外，需要说明的是，在本实施例中，将音频状态划分为静音状态和非静音状态。故而，上述所说的初始音频状态例如可以是静音状态，或者非静音状态。
56.进一步地，具体到实际应用中，为了便于机器内部快速识别，记录到音频状态表中的初始音频状态可以用预先约定的状态值（状态码）表示。
57.示例性的，在一些例子中，可以用“0”表示静音状态，用“1”表示非静音状态。
58.应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
59.为了更好的理解本实施例提供的技术方案，以下结合图2至图7对发起投屏连接请求的实现过程进行说明。
60.参见图2，示例性的，pc设备100的显示界面显示的是pc设备100的主页面。
61.可理解的，在实际应用中，主页面上可以包括一个或多个控件，例如视频应用控件、社交应用控件、浏览器控件，电脑管家应用控件，此处不再一一列举，本实施例对此也不做限制。
62.继续参见图2，具体到本实施例的技术方案中，pc设备100的主页面上包括投屏应用控件10。
63.此外，在pc设备100主界面底部的工具栏中可以包括一个或多个控件，例如设置pc设备100音频状态，例如调整为静音状态或非静音状态，以及调出音量条的声音设置控件20。
64.需要说明的是，图2及下面的附图中所涉及的pc设备100的显示界面显示的控件的名称和数量，以及弹出的界面中的控件的名称和数量仅为示意性举例，本技术不做限定。
65.继续参见图2，当用户想要将pc设备100的内容投屏到电视等大屏设备时，在用户点击主页面中的投屏应用控件10后，pc设备100响应于用户的操作行为，在显示界面显示发起投屏连接的页面，如图3所示。
66.参见图3，示例性的，发起投屏连接的页面中可以包括一个或多个选项。例如，发起投屏连接请求的“立即连接”选项10-1，可供用户选择投屏模式的选项。
67.继续参见图3，可供用户选择投屏模式的选项例如包括“镜像模式”选项和“扩展模式”选项。
68.所谓镜像模式，是指在投屏接收端，例如电视等大屏设备的显示器上镜像显示电脑屏幕，即pc设备100的屏幕上的内容。即，采用镜像模式建立pc设备100和大屏设备之间的投屏连接后，大屏设备的显示器显示的内容与pc设备100的屏幕显示的内容完全相同。
69.所谓扩展模式，是指在投屏接收端，例如电视等大屏设备的显示器上以扩展的方式显示电脑屏幕，即pc设备100的屏幕上的内容。即，采用扩展模式建立pc设备100和大屏设备之间的投屏连接后，大屏设备的显示器既显示pc设备100的屏幕显示的内容，又显示大屏设备本机的内容，类似多屏协同。
70.此外，需要说明的是，在实际应用中，投屏应用所要实现的功能也可以与其他功能集成到一个应用中，例如将驱动管理、电源管理等系统管理功能与投屏、多屏协同等提升用户体验的功能集成在一个应用中。
71.示例性的，该应用于例如可以成为“我的电脑”或者“电脑管家”等，本实施例对此不做限制。
72.参见图4，示例性的，当用户点击了功能列表中显示的“电脑互联”选项后，pc设备100响应于用户的操作行为，右侧的显示界面便会显示如图3所示的发起投屏连接的页面。
73.继续参见图3或图4，当用户选择了镜像模式后点击了“立即连接”选项10-1后，pc设备100响应于用户的操作行为，在显示界面上显示设备选择窗口10-2，如图5所示。
74.具体的说，设备选择窗口10-2用于显示当前可用设备，即可以作为投屏接收端的大屏设备，例如图5所示，当前可用设备有电视1、电视2和电视3。
75.继续参见图5，设备选择窗口10-2中还可以包括“查找其他显示设备”的选项，这样在当前显示的可用设备均不是用户要选择的设备时，用户可以通过点击“查找其他显示设备”的选项，跳转到查找其他显示设备的页面，并且pc设备100会开启搜索功能查找附件可
用的大屏设备。
76.可理解的，在实际的应用场景中，pc设备100与大屏设备建立投屏连接的前提例如可以是通过有线连接的方式，也可以是通过无线连接的方式。
77.示例性的，关于无线连接的方式，例如可以是二者接入了同一wlan网络，或者通过蓝牙匹配成功。
78.故而在投屏场景中pc设备100和大屏设备是采用无线方式建立连接的情况下，在用户点击了“立即连接”选项10-1后，pc设备100还需要确定本机是否开启了蓝牙或wlan。
79.相应地，如果pc设备100没有开启蓝牙或wlan，则pc设备100响应于用户的操作行为，在跳转到设备选择窗口10-2前会先开启蓝牙或wlan，然后跳转到设备搜索界面。
80.相应地，在搜索操作结束后，会跳转到设备选择窗口10-2，在设备选择窗口10-2中显示搜索到的可用设备。
81.此外，可理解的，在实际应用中，开启蓝牙或wlan的操作可以是由pc设备100自行完成的，也可以是跳转到开启蓝牙或wlan的界面，有用户开启的，本实施例对此不做限制。
82.继续参见图5，示例性的，当用户点击了电视1的选项后，pc设备100响应于用户的操作行为，在显示界面上显示连接窗口10-3，如图6所示。
83.参见图6，示例性的，显示连接窗口10-3中可以包括取消选项10-4。
84.示例性的，当用户点击取消选项10-4时，pc设备100响应于用户的操作行为，会返回到图5所示的界面。
85.示例性的，当pc设备100与电视1建立投屏连接后，pc设备100的显示界面会变更为图7所示的样式。
86.示例性的，在投屏连接成功的显示界面中可以包括一个或多个选项。例如图7中示出的断开连接选项10-5、声音输出设备选择选项10-6、可供用户选择投屏模式的选项，例如“镜像模式”选项和“扩展模式”选项。
87.应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
88.步骤102，确定用户选择的声音输出设备。
89.继续参见图7，当用户选择的声音输出设备为“电视1”时，确定声音输出设备为投屏接收端，即由投屏接收端出声。
90.相应地，当用户选择的声音输出设备为“本机”时，确定声音输出设备为投屏发送端。即由投屏发送端出声。
91.步骤103，声音输出设备是否为投屏发送端。
92.具体的说，如果确定的声音输出设备为投屏发送端，则执行步骤104的操作；否则执行步骤105的操作。
93.步骤104，将所述投屏发送端的音频状态设置为所述初始音频状态。
94.示例性的，如果音频状态表中记录的初始音频状态的状态值为“0”，即初始音频状态为静音状态，则将所述投屏发送端的音频状态设置为所述初始音频状态后，投屏发送端作为声音输出设备会静音，即不出声，此时投屏接收端的屏幕和投屏发送端的屏幕显示相同的画面，但是两个设备都不出声。
95.示例性的，如果音频状态表中记录的初始音频状态的状态值为“1”，即初始音频状
态对为非静音状态，则将所述投屏发送端的音频状态设置为所述初始音频状态后，投屏发送端作为声音输出设备会出声，此时投屏接收端的屏幕和投屏发送端的屏幕显示相同的画面，投屏接收端不出声。
96.步骤105，将所述投屏发送端设置为静音状态，将投屏信息中的音频数据发送至所述投屏接收端。
97.需要说明的是，在声音输出设备为投屏接收端时，不论音频状态表中记录的初始音频状态是静音状态还是非静音状态，投屏发送端和投屏接收端建立投屏后，投屏发送端均不能出声，因此投屏发送端中的投屏应用需要调用设置投屏发送端声音的接口，将投屏发送端设置为静音状态，然后将投屏信息中的音频数据通过传输模式发送至投屏接收端，这样投屏接收端接收到音频数据后便可以播放音频数据，即投屏接收端可以出声。
98.参见图8，示例性的，在pc设备100（投屏发送端）与电视200（投屏接收端）建立投屏连接后，如果电视200为声音输出设备，在镜像模式下，pc设备100的屏幕会显示画面30，而电视200的屏幕会显示与画面30相同的内容，例如图8中显示在电视200的画面30’，同时pc设备100不出声，电视200出声。
99.此外，需要说明的是，在声音输出设备为投屏接收端时，设置投屏发送端为静音状态的操作是系统实现的，而非用户修改的，因此该状态不记录在音频状态表中，故而不会对用户的操作造成干扰。
100.此外，可理解的，在实际应用中，传输模块发送至电视200的音频数据通常是进行音频编码处理后的音频数据包，这样既可以避免直接传输音频数据导致数据帧丢失，又可以避免音频数据直接暴露用户隐私。
101.此外，由于在实际应用中，使用投屏应用建立pc设备100与电视200之间的投屏连接时，pc设备100与电视200之间所遵循的协议会有所不同。因此，可以根据音频数据对应的协议类型来确定编码方式，进而采用确定的编码方式对音频数据进行编码。
102.具体的，传输模块在将投屏信息中的音频数据发送至所述投屏接收端，例如上文所说的电视200时，需要先确定所述音频数据对应的协议类型；然后，根据所述协议类型确定所述音频数据的目标编码方式；接着，根据所述目标编码方式对所述音频数据进行编码，得到音频数据包；最后，将所述音频数据包发送至所述投屏接收端。
103.相应地，在将所述音频数据包发送至所述投屏接收端时，将所述协议类型发送至所述投屏接收端。
104.这样，投屏接收端，如电视200就可以知道需要采用哪种解码方式对音频数据包解码，从而保证了解码结果的准确性。
105.此外，需要说明的是，关于上述所说的根据所述协议类型确定所述音频数据的目标编码方式，例如可以是通过投屏发送端和投屏接收端预先协商确定的编解码映射关系表来确定，即在编解码映射关系表中查找所述协议类型对应的编码方式，进而将查找到的编码方式确定为所述目标编码方式。
106.这样，投屏发送端和投屏接收端之间就可以不直接传输编码方式，从而避免了二者之间传输的内容被拦截，进而保证了音频数据的内容不被不法分子窃取，特别是针对音视频会议的使用场景，有效保证了会议安全性。
107.由此，在建立投屏连接前先获取pc设备100当前的音频状态，并将当前的音频状态
作为初始音频状态，将该初始音频状态对应的状态值记录到音频状态表中，从而可以获知用户在投屏过程中，期望pc设备100所处的音频状态，进而使得后续断开投屏，或者采用pc设备100作为声音输出设备时，pc设备100的音频状态能够与用户期望的相一致。
108.此外，需要说明的是，具体到实际的应用场景中，在pc设备100与大屏设备端建立投屏连接后，即在投屏的过程中，用户可能会手动修改pc设备100的音频状态，因此为了保证音频状态表中记录的初始音频状态的状态值能够根据用户实际修改动态更新，需要对音频状态切换控件进行监控。
109.具体到本实施例中，为了监控用户是否对pc设备100的音频状态切换控件进行了点击，借助了pc设备100使用的系统提供的音频状态监控模块。
110.具体的说，在执行完上述步骤101之后，pc设备100可以调用上述所说的音频状态监控模块，进而由音频状态监控模块监控用户对pc设备100的音频状态切换控件的点击操作。
111.需要说明的是，在所述音频状态切换控件对应的音频状态为上述所说的静音状态时，所述音频状态切换控件被点击后，所述音频状态从所述静音状态切换为上述所说的非静音状态。
112.相应地，在所述音频状态切换控件对应的音频状态为所述非静音状态时，所述音频状态切换控件被点击后，所述音频状态从所述非静音状态切换为所述静音状态。
113.由此，借助音频状态监控模块对音频状态切换控件的点击操作进行监控，在监控到用户对所述音频状态切换控件的点击操作后，根据切换后的所述音频状态更新所述音频状态表中记录的所述初始音频状态即可。
114.例如，在投屏连接前的初始音频状态对应的状态值为“0”时，当投屏连接后用户对音频状态切换控件进行点击后，pc设备100的音频状态会变更为非静音状态，此时对音频状态表的更新例如为将记录的状态值从“0”变更为“1”。
115.参见图9，示例性的，在投屏过程中，如果用户想要修改pc设备100的音频状态，用户可以先点击声音设置控件20。
116.相应地，在用户点击声音设置控件20后，pc设备100响应于用户的操作行为，会显示声音设置窗口20-1，如图10所示。
117.继续参见图9，示例性的，声音设置窗口20-1中可以显示当前可以播放音频数据的所有设备，例如图10中的扬声器，以及每一个播放音频数据的设备对应的音频状态切换控件20-2和调节音量的音量条控件20-3。
118.需要说明的是，图10中仅示出了一个播放音频数据的设备，即扬声器。在实际应用中，如果pc设备100接入了耳机（有线/蓝牙）、音响设备，则声音设置窗口20-1中还会显示耳机（有线/蓝牙）、音响设备对应的音频状态切换控件20-2和调节音量的音量条控件20-3。
119.继续参见图10，示例性的，如果用户点击了音频状态切换控件20-2，音频状态监控模块监听到该点击操作，pc设备响应于用户的操作行为，音频状态切换控件20-2的图标变化从图10所示的样式变为图11音频状态切换控件20-2的图标样式。即，表明初始音频状态从非静音状态变为了静音状态，此时会将音频状态表中记录的状态值从表示非静音状态的“1”变更为表示静音状态的“0”。
120.这样，便可以使音频状态表中记录的初始音频状态能够根据用户的实际操作进行
变更，进而保证断开投屏或者将声音输出设备变更为投屏发送端时根据音频状态表中记录的初始音频状态设置的音频状态与用户实际想要设置的音频状态相一致。
121.具体到实际应用中，根据音频状态表中记录的初始音频状态对pc设备100音频状态的设置，例如可以是：场景1：在用户将声音输出设备从电视等大屏设备，即投屏接收端变更为pc设备100，即投屏发送端后，读取所述音频状态表中记录的所述初始音频状态，具体为读取初始音频状态对应的状态值；然后将所述投屏发送端的音频状态设置为所述初始音频状态。
122.参见图12，示例性的，用户点击声音输出设备选择选项10-6后，pc设备100响应于用户的操作行为，会显示声音输出设备选择列表10-7。
123.示例性的，在一些例子中，例如音频数据要么由投屏发送端播放，要么由投屏接收端播放的场景下，声音输出设备选择列表10-7中可以包括当前连接的投屏接收端，例如图12中的电视1，以及投屏发送端，例如图12中的本机。
124.示例性的，在另一些例子中，例如音频数据还可以由其他第三方音频设备，例如音响播放的场景下，声音输出设备选择列表10-7中除了可以包括图12中示出的电视1、本机，还可以包括可用的第三方音频设备。
125.继续参见图12，如果用户选择了声音输出设备选择列表10-7中显示的本机选项，则声音输出设备会从由电视1出声切换为由pc设备100本机出声，pc设备100响应于用户的操作行为，声音输出设备选项10-6中显示的内容会从图12中的电视1变更为图13中的本机。
126.对于现有的方案，即未采用本实施例提供的投屏方法的方案中，在用户将声音输出设备从电视200切换为由pc设备100后，不论投屏过程中用户是否对pc设备的音频状态进行了修改，投屏过程中pc设备100均会出声，而电视200则不出声。
127.例如图14所示，声音设置选项20显示pc设备100当前的音频状态为静音状态，但是在pc设备100是声音输出设备的场景下，pc设备100依旧会发出声音，显然现有的方案会造成pc设备100的音频状态与用户期望的不一致。
128.具体到本实施例提供的技术方案，由于音频状态表中的初始音频状态会根据用户的操作实时更新，并且投屏过程中声音输出设备在从电视200切换到pc设备100后，是根据音频状态表中记录的初始音频状态来设置pc设备100的音频状态，这样声音输出设备从电视200切换为pc设备100后，pc设备100的音频状态能够与用户设置的状态相一致，从而解决了现有方案音频状态不一致的问题。
129.例如图15所示，声音设置选项20显示pc设备100当前的音频状态为静音状态，采用本实施例提供的技术方案，在pc设备100是声音输出设备的场景下，pc设备100作为声音输出设备当前不会出声，而是处于静音状态，即在这种场景下，pc设备100和电视200都只显示画面，不出声。
130.场景2：投屏管理模块在接收到投屏断开请求后通知音频管理模块读取所述音频状态表中记录的所述初始音频状态，然后将所述投屏发送端的音频状态设置为所述初始音频状态。
131.继续参见图13，示例性的，用户点击断开连接选项10-5后，pc设备100响应于用户的操作行为，pc设备100便会与电视200断开投屏连接。
132.可理解的，由于断开投屏后，pc设备100提供的投屏信息不会在通过传输模块发送
给电视200，因此电视200的屏幕不会在显示pc设备100屏幕显示的内容，同时电视200也不会播放pc设备100提供的投屏信息中的音频数据。
133.对于现有的方案，即未采用本实施例提供的投屏方法的方案中，在用户点击了断开连接选项10-5后，不论投屏过程中用户是否对pc设备的音频状态进行了修改，断开投屏后，系统会直接设置pc设备100出声，而电视200则不出声。
134.例如图16所示，声音设置选项20显示pc设备100当前的音频状态为静音状态，在于电视200断开投屏后，由于系统不知道投屏过程中用户修改本机的音频状态，因此pc设备100依旧会发出声音，显然现有的方案会造成pc设备100的音频状态与用户期望的不一致。
135.具体到本实施例提供的技术方案，由于音频状态表中的初始音频状态会根据用户的操作实时更新，并且断开投屏后，是根据音频状态表中记录的初始音频状态来设置pc设备100的音频状态，这样断开投屏后pc设备100的音频状态能够与用户设置的状态相一致，从而解决了现有方案音频状态不一致的问题。
136.例如图17所示，声音设置选项20显示pc设备100当前的音频状态为静音状态，采用本实施例提供的技术方案，在pc设备100断开与电视200之间的投屏连接后，pc设备100的音频状态会设置为音频状态表中记录的初始音频状态，即静音状态，在这种场景下，pc设备100只显示画面，不出声，而电视200则既不现实pc设备100的屏幕显示的画面，也不出声。
137.此外，需要说明的是，由于投屏过程中音频状态监控模块一直在监听用户对音频状态切换控件的点击操作，因此在投屏结束后，即断开投屏后，需要关闭音频状态监控模块，即停止继续监控音频状态的变化，从而避免对pc设备100资源的占用和浪费。
138.由此，本技术提供的投屏方案，通过在投屏场景中通过获取投屏发送端在建立投屏连接前的音频状态，并将获取到的音频状态作为投屏发送端的初始音频状态记录到音频状态表，这样在确定用户选择的声音输出设备为投屏发送端时，直接将投屏发送端的音频状态设置为音频状态表中记录的初始音频状态，从而使得投屏场景中，在声音切回到投屏发送端时，投屏发送端的音频状态能够与用户期望的音频状态一致，进而大大提升了用户体验。
139.此外，需要说明的是，在实际应用中，如果用户点击了调节音量的音量条控件20-3，pc设备响应于用户的操作行为，会改变输出的音频数据的音量大小，这样如果在声音输出设备为大屏设备时，由于从pc设备接收到的音频数据是根据调节后音量编码得到的，因此大屏设备播放的音频数据会与音量条控件20-3调节后的音量同步，例如在用户是通过音量条控件20-3将音量调高时，大屏设备播放的音频数据的音量也会调高，在用户是通过音量条控件20-3将音量调低时，大屏设备播放的音频数据的音量也会调低。
140.此外，具体到实际应用中，本实施例提供的技术方案可以通过两种实现方式实现。
141.方式1：投屏过程中通过由音频管理模块来设置投屏发送端的音频状态。
142.参见图18，示例性的，为了更好的理解本实施例提供的技术方案，以投屏前pc机先静音，然后播放音频进行投屏（首次连接投屏时大屏设备，如图18中的电视1出声），之后切换声音到本机，即切换到pc机，然后切换回电视1，最后断开投屏连接的场景进行说明。
143.继续参见图18，示例性的，在用户点击进行投屏时，上层投屏管理模块（例如可以称为multicastmgr）通过audiocontol.init()方法通知音频管理模块（例如可以称为audiocontrol）；然后音频管理模块通过savemutestate()获取目前的音频状态为静音状
态，并将静音状态对应的状态值“0”保存为初始值，同时调用setdevicemute()设置本机静音，之后开启监控pc的音频状态listenvolchange()。
144.需要说明的是，在实际应用中，音频模块调用setdevicemute()设置本机静音的操作和调用listenvolchange()开启监控pc的音频状态的操作不区分执行顺序。
145.继续参见图18，示例性的，在执行上述操作的过程中，产品上层会通知对应的协议层，即传输模块声音输出设备为大屏（电视1），此时传输模块收到上层通知后通过speakerencoder()将pc机的音频编解并打包发送给电视1，使得电视1对音频解码后出声。
146.继续参见图18，示例性的，当切换声音为本机时，上层投屏管理模块通过audiocontol.init()方法通知音频管理模块，产品上层通知传输模块不将音频编解并打包发送到电视1，即停止编码，并调用audiostop()，这样电视1接收不到音频数据包，就无法解码获得音频数据进行播放，故而电视1会静音。
147.同时音频管理模块使用方法haudiodevice ()查询pc机目前的音频状态。
148.相应地，在音频状态为静音状态时，通过setdevicemute ()设置本机静音；在音频状态为非静音状态时，通过setdevicemute ()设置本机出声。
149.接着，在从本机出声切换回大屏出声时，实现流程与首次连接投屏时默认大屏出声时执行的流程类似，只是不需要重新调用listenvolchange()。
150.继续参见图18，示例性的，当断开投屏连接时，音频管理模块通过devicestop()通知传输模块断开与电视1之间的投屏连接，同时通过stopnotifydevicechange()关闭监控pc机的音频状态的音频状态监控模块。
151.同时音频管理模块使用方法haudiodevice ()查询pc机目前的音频状态。
152.相应地，在音频状态为静音状态时，通过setdevicemute ()设置本机静音；在音频状态为非静音状态时，通过setdevicemute ()设置本机出声。
153.此外，音频管理模块还会通知传输模块不将音频编解并打包发送到电视1，即停止编码，并调用audiostop()这样电视1接收不到音频数据包，就无法解码获得音频数据进行播放，故而电视1会静音。
154.为了更好的理解图18中示出的三种场景下基于本实施例提供的技术方案实现的投屏处理，以下结合图19至图21进行详细说明。
155.参见图19，示例性的，将投屏发送端称为pc机，将投屏接收端称为电视1。
156.其中，pc机安装有投屏应用，投屏应用包括投屏管理模块、音频管理模块和传输模块。
157.此外，pc机使用的系统提供有音频状态监控模块。
158.假设pc机和电视1首次建立投屏连接时，声音输出设备默认为电视1，即由电视1出声。
159.继续参见图19，示例性的，在有用户点击图3或图4中的“立即连接”选项10-1时，投屏管理模块会接收到向电视1投屏的投屏连接请求，即步骤201。
160.接着，投屏管理模块会执行步骤202，向音频管理模块发送初始化指令。
161.相应地，音频管理模块在接收到投屏管理模块发送的初始化指令后，会执行步骤203进行初始化操作，例如通过调用audiocontol.init()接口实现初始化。
162.接着，音频管理模块在初始化后，会获取本机的音频状态。
163.具体到实际应用中，音频管理模块获取本机的音频状态的操作可以是通过预先编译好的程序接口实现。
164.示例性的，在本实施例中，将该程序接口称为savemutestate()。
165.音频管理模块通过调用savemutestate()便可以获取到pc机目前的音频状态为静音状态，还是非静音状态。
166.相应地，如果音频管理模块通过步骤204获取到本机的音频状态为静音状态，紧接着会执行步骤205，具体为将步骤204中获取到的静音状态对应的状态值，如“0”保存到音频状态表。
167.之后，音频管理模块会向音频状态监控模块发送监控本机音频状态的请求，即执行步骤206。
168.具体到本实施例中，调用音频状态监控模块开启监控pc机的音频状态的操作，例如是通过调用预先编译的listenvolchange()接口。
169.示例性的，音频状态监控模块启动后，在整个投屏过程中，即断开投屏前会一致执行步骤207的操作监控音频状态是否变化。
170.相应地，若果监听到音频状态发生变化，则执行步骤208，否则继续执行步骤207。
171.示例性的，由于图19示出的场景中，pc机的初始音频状态为静音状态，因此音频状态监控模块监听到音频状态发生变化时，是用户点击了音频状态切换控件，使得pc机的音频状态变更为非静音状态，因此步骤208具体是向音频管理模块发送非静音状态对应的状态值，例如“1”。
172.接着，音频管理模块根据接收到的非静音状态对应的状态值“1”对音频状态表中记录的初始音频状态的状态值进行更新，具体为将音频状态表中的状态值从0更新为1，即执行步骤209。
173.同时，音频管理模块还会通知传输模块声音输出设备为电视1，并通过设置音频状态的接口，例如称为setdevicemute()，设置本机的音频设备，例如扬声器为静音，即执行步骤210将本机设置为静音状态。
174.需要说明的是，在实际应用中，步骤210的操作可以在音频管理模块执行完步骤203后，与步骤204同步执行，本实施例对此不做限制。
175.接着，在完成上述步骤210的操作后，音频管理模块会将投屏信息中的音频数据发送给传输模块，即执行步骤211。
176.相应地，传输模块接收到音频数据后，会对采用上述步骤105中所说的方式对音频数据进行编码，进而得到音频数据包，即执行步骤212。
177.接着，传输模块会将得到的音频数据包通过建立的投屏链路发送至电视1，即执行步骤213。
178.相应地，电视1在接收到传输模块发送的音频数据包后会执行步骤214对音频数据包进行解码操作，进而还原出音频数据，并播放音频数据，实现电视1出声。
179.由此，实现了pc机先静音，然后播放视频后进行投屏，由电视1出声，并在投屏过程中由音频管理模块根据用户对pc机的音频状态的修改更新音频状态表中记录的初始音频状态对应的状态值的过程，这样既不影响用户使用投屏功能，又能够实时监控用户在投屏过程中对pc机音频状态的修改。
180.进一步地，在pc机的投屏信息发送到电视1，电视1开始播放投屏信息中的画面，并播放音频数据后，如果用户将声音输出设备由电视1切换为了pc机，则对pc机音频状态的设置过程可以参见图20。
181.示例性的，如果投屏管理模块监听到用户切换声音输出设备的操作，并确定声音输出设备切换为本机，即步骤215的操作后，投屏管理模块会向音频管理模块重新发送初始化指令，即执行步骤216。
182.相应地，音频管理模块在接收到投屏管理模块发送的初始化指令后，会执行步骤217进行初始化操作，例如通过调用audiocontol.init()接口实现初始化。
183.接着，音频管理模块在初始化后，会从音频状态表中读取记录的音频状态的状态值。
184.示例性的，以音频状态表中记录的音频状态的状态值为“1”为例，即投屏前或投屏过程中用户将pc机的音频状态修改为了非静音状态，则音频管理模块在初始化后，从音频状态表中读取记录的音频状态的状态值为“1”，即步骤218的内容。
185.接着，音频管理模块根据读取出的状态值“1”将本机设置为非静音状态，即执行步骤219的操作，然后执行步骤220的操作播放音频数据。
186.示例性的，如果音频状态表中记录的音频状态的状态值为“0”，即投屏前或投屏过程中用户将pc机的音频状态修改为了静音状态，则音频管理模块在初始化后，从音频状态表中读取记录的音频状态的状态值为“0”。
187.相应地，音频管理模块在从音频状态表中读取出状态值“0”后，会根据读取出的状态值“0”将本机设置为静音状态，然后播放音频数据。
188.可理解的，由于pc机的音频状态被设置成了静音状态，因此即便音频数据是由pc机播放，但是由于pc机的音频状态时静音状态，故而播放音频数据的过程中也不会发出声音。
189.此外，需要说明的是，虽然在图20中未示出音频状态监控模块执行的操作，但是音频状态监控模块被启动后，在整个投屏过程中始终是处于工作状态，即在执行步骤215值步骤220的过程中，只要用户修改了音频状态图19中步骤207至步骤209的操作就会执行。
190.此外，由于图20所示的投屏场景是用户将声音输出设备由电视1切换为了pc机，因此传输模块不会在向电视1发送音频数据包，电视1接收不到音频数据包，也就不会发出声音。
191.此外，可理解的，由于本实施例提供的技术方案是针对投屏场景中音频数据的，因此关于视频数据的发送并未在图中示出。
192.由此，实现了投屏过程中将声音输出设备由电视1切换为pc机，然后由音频管理模块根据音频状态表中记录的状态值设置pc机音频状态的过程，从而使得声音输出设备修改为pc机后，pc机的音频状态能够与用户设置的一致。
193.进一步地，在完成图20的操作，pc机开始播放音频数据，电视1继续播放投屏信息中的画面/视频数据后，如果用户点击了图7中的断开连接选项10-5，则对pc机音频状态的设置过程可以参见图21。
194.示例性的，如果投屏管理模块接收到投屏断开请求，即步骤221的操作，投屏管理模块会向音频管理模块重新发送初始化指令，即执行步骤222。
195.相应地，音频管理模块在接收到投屏管理模块发送的初始化指令后，会执行步骤223进行初始化操作，例如通过调用audiocontol.init()接口实现初始化。
196.接着，音频管理模块在初始化后，会从音频状态表中读取记录的音频状态的状态值。
197.示例性的，以音频状态表中记录的音频状态的状态值为“1”为例，即投屏前或投屏过程中用户将pc机的音频状态修改为了非静音状态，则音频管理模块在初始化后，从音频状态表中读取记录的音频状态的状态值为“1”，即步骤224的内容。
198.接着，音频管理模块根据读取出的状态值“1”将本机设置为非静音状态，即执行步骤225的操作，然后执行步骤226的操作播放音频数据。
199.示例性的，如果音频状态表中记录的音频状态的状态值为“0”，即投屏前或投屏过程中用户将pc机的音频状态修改为了静音状态，则音频管理模块在初始化后，从音频状态表中读取记录的音频状态的状态值为“0”。
200.相应地，音频管理模块在从音频状态表中读取出状态值“0”后，会根据读取出的状态值“0”将本机设置为静音状态，然后播放音频数据。
201.可理解的，由于pc机的音频状态被设置成了静音状态，因此即便音频数据是由pc机播放，但是由于pc机的音频状态时静音状态，故而播放音频数据的过程中也不会发出声音。
202.此外，在断开投屏后，音频管理模块还会向音频状态监控模块发送停止监控本机音频状态的请求，即执行步骤227。
203.相应地，音频状态监控模块在接收到音频管理模块发送的停止监控本机音频状态的请求后，会执行步骤228的操作，停止监听本机的音频状态。
204.示例性的，音频状态监控模块例如可以调用预先封装的stopnotifyvolchange()接口，从而停止监听本机的音频状态。
205.由此，本技术提供的投屏方案，在投屏过程中通过由音频管理模块来设置投屏发送端的音频状态，这样不管投屏应用采用的是哪种协议，音频管理模块只需采用统一的方式进行设置即可，大大减小了开发工作量和维护难。
206.方式2：投屏过程中通过由传输模块来设置投屏发送端的音频状态。
207.参见图22，示例性的，为了更好的理解本实施例提供的技术方案，以投屏前pc机先静音，然后播放音频进行投屏（首次连接投屏时大屏设备，如图22中的电视1出声），之后切换声音到本机，即切换到pc机，然后切换回电视1，最后断开投屏连接的场景进行说明。
208.继续参见图22，示例性的，在用户点击进行投屏时，上层投屏管理模块（例如可以称为multicastmgr）通过audiocontol.init()方法通知音频管理模块（例如可以称为audiocontrol）；然后音频管理模块通过savemutestate()获取目前的音频状态为静音状态，并将静音状态对应的状态值“0”保存为初始值，之后开启监控pc的音频状态listenvolchange()。
209.需要说明的是，在实际应用中，音频模块调用setdevicemute()设置本机静音的操作和调用listenvolchange()开启监控pc的音频状态的操作不区分执行顺序。
210.继续参见图22，示例性的，在执行上述操作的过程中，产品上层会通知对应的协议层，即传输模块声音输出设备为大屏（电视1），此时传输模块收到上层通知后通过
speakerencoder()将pc机的音频编解并打包发送给电视1，使得电视1对音频解码后出声，同时调用setdevicemute()设置本机静音。
211.继续参见图22，示例性的，当切换声音为本机时，上层投屏管理模块通过audiocontol.init()方法通知音频管理模块，产品上层通知传输模块不将音频编解并打包发送到电视1，即停止编码，并调用audiostop()这样电视1接收不到音频数据包，就无法解码获得音频数据进行播放，故而电视1会静音。
212.同时音频管理模块使用方法haudiodevice ()查询pc机目前的音频状态。
213.相应地，在音频状态为静音状态时，通知传输模块通过setdevicemute ()设置本机静音；在音频状态为非静音状态时，通过setdevicemute ()设置本机出声。
214.接着，在从本机出声切换回大屏出声时，实现流程与首次连接投屏时默认大屏出声时执行的流程类似，只是不需要重新调用listenvolchange()。
215.继续参见图22，示例性的，当断开投屏连接时，音频管理模块通过devicestop()通知传输模块断开与电视1之间的投屏连接，同时通过stopnotifydevicechange()关闭监控pc机的音频状态的音频状态监控模块。
216.同时音频管理模块使用方法haudiodevice ()查询pc机目前的音频状态。
217.相应地，在音频状态为静音状态时，通知传输模块通过setdevicemute ()设置本机静音；在音频状态为非静音状态时，通过setdevicemute ()设置本机出声。
218.此外，音频管理模块还会通知传输模块不将音频编解并打包发送到电视1，即停止编码，并调用audiostop()这样电视1接收不到音频数据包，就无法解码获得音频数据进行播放，故而电视1会静音。
219.为了更好的理解图22中示出的三种场景下基于本实施例提供的技术方案实现的投屏处理，以下结合图23至图25进行详细说明。
220.参见图23，示例性的，将投屏发送端称为pc机，将投屏接收端称为电视1。
221.其中，pc机安装有投屏应用，投屏应用包括投屏管理模块、音频管理模块和传输模块。
222.此外，pc机使用的系统提供有音频状态监控模块。
223.假设pc机和电视1首次建立投屏连接时，声音输出设备默认为电视1，即由电视1出声。
224.继续参见图23，示例性的，在有用户点击图3或图4中的“立即连接”选项10-1时，投屏管理模块会接收到向电视1投屏的投屏连接请求，即步骤301。
225.接着，投屏管理模块会执行步骤302，向音频管理模块发送初始化指令。
226.相应地，音频管理模块在接收到投屏管理模块发送的初始化指令后，会执行步骤303进行初始化操作，例如通过调用audiocontol.init()接口实现初始化。
227.接着，音频管理模块在初始化后，会获取本机的音频状态。
228.具体到实际应用中，音频管理模块获取本机的音频状态的操作可以是通过预先编译好的程序接口实现。
229.示例性的，在本实施例中，将该程序接口称为savemutestate()。
230.音频管理模块通过调用savemutestate()便可以获取到pc机目前的音频状态为静音状态，还是非静音状态。
231.相应地，如果音频管理模块通过步骤304获取到本机的音频状态为静音状态，紧接着会执行步骤305，具体为将步骤304中获取到的静音状态对应的状态值，如“0”保存到音频状态表。
232.之后，音频管理模块会向音频状态监控模块发送监控本机音频状态的请求，即执行步骤306。
233.具体到本实施例中，调用音频状态监控模块开启监控pc机的音频状态的操作，例如是通过调用预先编译的listenvolchange()接口。
234.示例性的，音频状态监控模块启动后，在整个投屏过程中，即断开投屏前会一致执行步骤307的操作监控音频状态是否变化。
235.相应地，若果监听到音频状态发生变化，则执行步骤308，否则继续执行步骤307。
236.示例性的，由于图23示出的场景中，pc机的初始音频状态为静音状态，因此音频状态监控模块监听到音频状态发生变化时，是用户点击了音频状态切换控件，使得pc机的音频状态变更为非静音状态，因此步骤308具体是向音频管理模块发送非静音状态对应的状态值，例如“1”。
237.接着，音频管理模块根据接收到的非静音状态对应的状态值“1”对音频状态表中记录的初始音频状态的状态值进行更新，具体为将音频状态表中的状态值从0更新为1，即执行步骤309。
238.由于本实施例中设置本机音频状态的操作是由传输模块实现的，因此传输模块会通过设置音频状态的接口，例如称为setdevicemute()，设置本机的音频设备，例如扬声器为静音，即执行步骤310将本机设置为静音状态。
239.可理解的，由于声音输出设备为电视1时，投屏过程中无论pc机的音频状态是静音状态还是非静音状态，pc机的音频设备，例如扬声器都不会出声，因此这种场景下，传输模块之间调用设置音频状态的接口设置本机的音频设备，例如扬声器为静音即可。
240.需要说明的是，在实际应用中，步骤310的操作可以在音频管理模块执行完步骤303后，与步骤304同步执行，本实施例对此不做限制。
241.接着，在完成上述步骤310的操作后，音频管理模块会将投屏信息中的音频数据发送给传输模块，即执行步骤311。
242.相应地，传输模块接收到音频数据后，会对采用上述步骤105中所说的方式对音频数据进行编码，进而得到音频数据包，即执行步骤312。
243.接着，传输模块会将得到的音频数据包通过建立的投屏链路发送至电视1，即执行步骤313。
244.示例性的，根据传输模块实现的功能，在实际应用中，传输模块可以包括音频服务模块、音频编码模块和打包发送模块。
245.相应地，音频服务模块用于执行步骤310的操作，音频编码模块用于执行步骤312的操作，打包发送模块用于执行步骤313的操作。
246.相应地，电视1在接收到传输模块发送的音频数据包后会执行步骤314对音频数据包进行解码操作，进而还原出音频数据，并播放音频数据，实现电视1出声。
247.由此，实现了pc机先静音，然后播放视频后进行投屏，由电视1出声，并在投屏过程中由传输模块根据用户对pc机的音频状态的修改更新音频状态表中记录的初始音频状态
对应的状态值的过程，这样既不影响用户使用投屏功能，又能够实时监控用户在投屏过程中对pc机音频状态的修改。
248.进一步地，在pc机的投屏信息发送到电视1，电视1开始播放投屏信息中的画面，并播放音频数据后，如果用户将声音输出设备由电视1切换为了pc机，则对pc机音频状态的设置过程可以参见图24。
249.示例性的，如果投屏管理模块监听到用户切换声音输出设备的操作，并确定声音输出设备切换为本机，即步骤315的操作后，投屏管理模块会向音频管理模块重新发送初始化指令，即执行步骤316。
250.相应地，音频管理模块在接收到投屏管理模块发送的初始化指令后，会执行步骤317进行初始化操作，例如通过调用audiocontol.init()接口实现初始化。
251.由于本实施例中设置本机音频状态的操作是由传输模块实现的，而在将声音输出设备切换为pc机时，为了保证设置的音频状态与用户期望的音频状态一致，因此传输模块需要向记管理音频状态表的音频管理模块发送音频状态查询请求，即执行步骤318。
252.相应地，音频管理模块在接收到传输模块发送的音频状态查询请求后，会从音频状态表中读取记录的音频状态的状态值，并将读取出的状态值发送给传输模块。
253.示例性的，以音频状态表中记录的音频状态的状态值为“1”为例，即投屏前或投屏过程中用户将pc机的音频状态修改为了非静音状态，则音频管理模块在接收到传输模块发送的音频状态查询请求后，从音频状态表中读取记录的音频状态的状态值为“1”，即步骤319的内容。
254.接着，音频管理模块会将读取出的状态值“1”发送给传输模块，即执行步骤320。
255.接着，传输模块根据接收到的状态值“1”，执行步骤321，将本机设置为非静音状态。
256.示例性的，如果音频状态表中记录的音频状态的状态值为“0”，即投屏前或投屏过程中用户将pc机的音频状态修改为了静音状态，则音频管理模块在接收到传输模块发送的音频状态查询请求后，从音频状态表中读取记录的音频状态的状态值为“0”。
257.接着，音频管理模块会将读取出的状态值“0”发送给传输模块；然后，传输模块根据接收到的状态值“0”，将本机设置为非静音状态。
258.相应地，音频管理模块在从音频状态表中读取出状态值后，向传输模块发送了读取出的状态值后，会执行步骤322播放音频数据。
259.可理解的，由于pc机的音频状态被设置成了静音状态，因此即便音频数据是由pc机播放，但是由于pc机的音频状态时静音状态，故而播放音频数据的过程中也不会发出声音。
260.此外，需要说明的是，虽然在图24中未示出音频状态监控模块执行的操作，但是音频状态监控模块被启动后，在整个投屏过程中始终是处于工作状态，即在执行步骤315值步骤322的过程中，只要用户修改了音频状态图23中步骤307至步骤309的操作就会执行。
261.此外，由于图24所示的投屏场景是用户将声音输出设备由电视1切换为了pc机，因此传输模块不会在向电视1发送音频数据包，电视1接收不到音频数据包，也就不会发出声音。
262.此外，可理解的，由于本实施例提供的技术方案是针对投屏场景中音频数据的，因
此关于视频数据的发送并未在图中示出。
263.由此，实现了投屏过程中将声音输出设备由电视1切换为pc机，然后由传输模块根据音频状态表中记录的状态值设置pc机音频状态的过程，从而使得声音输出设备修改为pc机后，pc机的音频状态能够与用户设置的一致。
264.进一步地，在完成图24的操作，pc机开始播放音频数据，电视1继续播放投屏信息中的画面/视频数据后，如果用户点击了图7中的断开连接选项10-5，则对pc机音频状态的设置过程可以参见图25。
265.示例性的，如果投屏管理模块接收到投屏断开请求，即步骤323的操作，投屏管理模块会向音频管理模块重新发送初始化指令，即执行步骤324。
266.相应地，音频管理模块在接收到投屏管理模块发送的初始化指令后，会执行步骤325进行初始化操作，例如通过调用audiocontol.init()接口实现初始化。
267.由于本实施例中设置本机音频状态的操作是由传输模块实现的，而在将声音输出设备切换为pc机时，为了保证设置的音频状态与用户期望的音频状态一致，因此传输模块需要向记管理音频状态表的音频管理模块发送音频状态查询请求，即执行步骤326。
268.相应地，音频管理模块在接收到传输模块发送的音频状态查询请求后，会从音频状态表中读取记录的音频状态的状态值，并将读取出的状态值发送给传输模块。
269.示例性的，以音频状态表中记录的音频状态的状态值为“1”为例，即投屏前或投屏过程中用户将pc机的音频状态修改为了非静音状态，则音频管理模块在接收到传输模块发送的音频状态查询请求后，从音频状态表中读取记录的音频状态的状态值为“1”，即步骤327的内容。
270.接着，音频管理模块会将读取出的状态值“1”发送给传输模块，即执行步骤328。
271.接着，传输模块根据接收到的状态值“1”，执行步骤329，将本机设置为非静音状态。
272.示例性的，如果音频状态表中记录的音频状态的状态值为“0”，即投屏前或投屏过程中用户将pc机的音频状态修改为了静音状态，则音频管理模块在接收到传输模块发送的音频状态查询请求后，从音频状态表中读取记录的音频状态的状态值为“0”。
273.接着，音频管理模块会将读取出的状态值“0”发送给传输模块；然后，传输模块根据接收到的状态值“0”，将本机设置为非静音状态。
274.相应地，音频管理模块在从音频状态表中读取出状态值后，向传输模块发送了读取出的状态值后，会执行步骤330播放音频数据。
275.可理解的，由于pc机的音频状态被设置成了静音状态，因此即便音频数据是由pc机播放，但是由于pc机的音频状态时静音状态，故而播放音频数据的过程中也不会发出声音。
276.此外，在断开投屏后，音频管理模块还会向音频状态监控模块发送停止监控本机音频状态的请求，即执行步骤331。
277.相应地，音频状态监控模块在接收到音频管理模块发送的停止监控本机音频状态的请求后，会执行步骤332的操作，停止监听本机的音频状态。
278.示例性的，音频状态监控模块例如可以调用预先封装的stopnotifyvolchange()接口，从而停止监听本机的音频状态。
279.由此，本技术提供的投屏方案，在投屏过程中通过由传输模块来设置投屏发送端的音频状态，这样采用不同协议的投屏应用能够根据实际需求个性化设置，使得本技术提供的投屏方案更加多元化。
280.此外，应当理解的是，上述实施例中使用的各方法接口仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
281.此外，需要说明的是，在实际的应用场景中由电子设备实现的上述各实施例提供的系统投屏方法，也可以由电子设备中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。
282.另外，本技术实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的系统投屏方法。
283.另外，本技术实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的系统投屏方法。
284.另外，本技术的实施例还提供一种芯片（也可以是组件或模块），该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的系统投屏方法，以控制接收管脚接收信号，以控制发送管脚发送信号。
285.此外，通过上述描述可知，本技术实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
286.以上所述，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。