CN103701854A - 基于应用虚拟化的网络实时音频传输方法 - Google Patents

Abstract

一种基于应用虚拟化的网络实时音频传输方法，应用于服务端，该方法包括：重定向步骤，当用户在客户端上要使用服务端上的应用时，利用服务端的应用层声音捕捉装置实时捕捉服务端的所述应用产生的音频内容；处理步骤，对所捕获的音频内容进行处理以转换为客户端能够识别的音频数据格式；发送步骤，将处理后的音频内容通过网络传输给客户端。本发明可以在不支持大型3D游戏的客户端设备上支持游戏音频的实时回放；并可以在原先不支持现有网游的客户端设备上支持网游音频回放，大大扩展了游戏的受众范围。

Description

基于应用虚拟化的网络实时音频传输方法

技术领域

本发明涉及应用虚拟化领域，特别涉及一种基于应用虚拟化的网络实时音频传输方法。

背景技术

随着智能手机的普及与发展，智能手机的应用种类不断丰富，人们对应用的要求不断提高，覆盖了交流、办公、娱乐等各个方面。同时随着3G、4G网络的发展，移动终端对多媒体服务的需求越来越强烈。然而，与此相对的是，受制于芯片制作工艺和功耗的限制，移动设备的计算能力先天不足，无法满足大型实时多媒体相关应用的需求，特别是3D渲染和大型游戏的需求。即使是最新的高端智能手机，受制于移动平台的计算能力，也难以实现3D图像的高效渲染与大型游戏的流畅运行。这一瓶颈在很大程度上限制了智能手机和相关应用的进一步发展，而解决这一问题的一种可行方法就是通过应用虚拟化实现运算和交互部分的分离。

应用虚拟化的一种常见实现方式是采用客户端/服务端的架构。其具体做法是：将应用中计算密集的主要处理逻辑与交互密集的界面显示、输入输出部分进行分离，性能较差的客户端仅负责图形显示、声音播放以及操作输入部分，应用自身则在性能较好的服务端运行。

发明内容

鉴于以上内容，有必要提供一种基于应用虚拟化的网络实时音频传输方法，可以在不支持大型3D游戏的客户端设备上支持游戏音频的实时回放；并可以在原先不支持现有网游的客户端设备上（尤其是便携式设备）支持网游音频回放，大大扩展了游戏的受众范围。

一种基于应用虚拟化的网络实时音频传输方法，应用于服务端，该方法包括：重定向步骤，当用户在客户端上要使用服务端上的应用时，利用服务端的应用层声音捕捉装置实时捕捉服务端的所述应用产生的音频内容；处理步骤，对所捕获的音频内容进行处理以转换为客户端能够识别的音频数据格式；发送步骤，将处理后的音频内容通过网络传输给客户端。

相较于现有技术，所述基于应用虚拟化的网络实时音频传输方法，其能够采用重定向Windows Core Audio API的方式获取服务端中的应用的音频数据，对所获取的音频数据进行码率转换以及数据类型的修正后，通过网络将处理后的音频数据传输至客户端以使用户在桌面和移动平台上实时播放客户端所接收的音频数据。

附图说明

图1是本发明基于应用虚拟化的网络实时音频传输系统的应用环境图。

图2是本发明的服务端架构图。

图3是本发明Windows Core Audio API接口的参数列表。

图4是本发明基于应用虚拟化的网络实时音频传输方法的较佳实施例的流程图。

主要元件符号说明

如下具体实施方式将结合上述附图进一步说明本发明。

具体实施方式

如图1所示，是本发明基于应用虚拟化的网络实时音频传输系统10(以下简称系统10)较佳实施例的应用环境图。该系统10运行于服务端1中。该服务端1可与多个客户端2相通信。所述服务端1可以是电脑、服务器等可以通信的电子设备，客户端2可以是电脑、手机、PDA（Personal DigitalAssistant，个人数字助理）等可以通信的电子设备。

该服务端1还包括通过数据总线相连的存储器20、处理器30、显示设备40及输入设备50。存储器20中有多个应用（即应用程序，Application），该应用可以是与3D图像的高效渲染及大型3D游戏的相关的应用。存储器20中还用于存储系统10的程序代码及其它数据资料。所述显示设备40可以是电脑的液晶显示屏、手机的触摸屏等。所述输入设备50用于输入用户设置的各种数据，例如，键盘、鼠标等。

该系统10采用重定向Windows Core Audio API的方式获取服务端1中的应用的音频数据，对所获取的音频数据进行码率转换以及数据类型的修正后，通过网络将处理后的音频数据传输至客户端2以使用户在桌面和移动平台上实时播放客户端2所接收的音频数据。

所述基于应用虚拟化的网络实时音频传输系统10由一个或者多个模块构成，所述模块还包括重定向模块101、处理模块102及发送模块103，所述模块的功能将在后续中详述。

如图2所示，为服务端1上系统10的架构图，当用户在客户端2上要使用服务端1上的应用时，在服务端1上启动该应用，在应用启动及获得焦点（如窗口的焦点）时会触发服务端1上的Windows系统消息（简称“消息”），当重定向模块101通过Windows Hook子程（简称“Hook子程”）捕获到该消息后，系统10就会知道服务端1开始运行了该应用，然后利用重定向模块101重定向服务端1中与音频相关的Windows系统API（即重定向Windows Core Audio API），使用服务端1的功能函数替换服务端1中与音频相关的系统API，这样重定向Windows Core Audio API后，当该应用调用所述系统API时，实际上调用的是服务端1的功能函数，系統10通过功能函数获得Windows系统的音频缓冲区地址，从而可以高效直接的得到该应用的音频数据，处理模块102对音频数据进行处理，并通过发送模块103将处理后的音频数据发送给客户端2，在客户端2上就可以进行图像显示与声音回放。

所述功能函数与所述系统API函数的参数、返回值等特征保持一致，功能函数用于替换服务端1中与音频相关的系统API，用以通过功能函数捕捉服务端1对所述系统API的调用，从而获取该应用写入服务端1的硬件（如声卡，音频采集设备）的音频数据。例如，初始化功能函数CA_Initialize的参数与所述系统API中接口IAudioClient的Initialize函数一致。

如图3所示，为本发明Windows Core Audio API接口的参数列表。在Windows系统中，服务端1中的应用可以通过WASAPI族的IAudioClient接口和IAudioRenderClient接口访问和管理音频流，对IAudioClient中的Start、Stop、Reset、Initialize函数的入口进行重定向以实现对该应用的音频的格式、码率等音频元数据的获取，对GetService函数的入口进行重定向以获得运行时IAudioRenderClient实例的地址，并进一步通过对IAudioRenderClient接口中GetBuffer和ReleaseBuffer函数的入口进行重定向，实现了对具体音频数据的获取以及缓存。

如图4所示，是本发明基于应用虚拟化的网络实时音频传输系统10的较佳实施例的流程图。根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。

步骤S11，当用户在客户端2上要使用服务端1上的应用时，重定向模块101利用服务端1的应用层声音捕捉装置实时捕捉服务端1的所述应用产生的音频内容。

重定向模块101实时捕捉服务端1的所述应用产生的音频数据的过程如下：

（1.1）重定向模块101通过Hook子程捕捉服务端1上的所述应用的消息。

当用户在客户端2上要使用服务端1上的所述应用时，服务端1上的所述应用启动，当服务端1的操作系统收到与所述应用有关的一些窗口操作或者事件的消息时，如建立、激活、关闭、最大化、最小化、拖动等窗口操作的消息，鼠标、键盘事件的消息，输入焦点（如窗口的焦点）获取的消息，及消息队列同步等事件的消息，Windows系统就会触发WH_CBTHook回调函数（简称“Hook回调函数”）进行消息响应。

重定向模块101通过将Hook回调函数加入WH_CBT Hook对应的Hook链表中以实现对多个应用的窗口建立（HCBT_ACTIVATE）和窗口获得焦点（HCBT_SETFOCUS）的消息的捕捉。当重定向模块101捕捉到所述消息后，标志着服务端1开始运行某个应用。重定向模块101通过Hook回调函数判断所捕捉到所述消息是否为所述应用的消息，当所捕捉到所述消息不是所述应用的消息时，重定向模块101会继续捕捉；当所捕捉到所述消息是所述应用的消息时，就会对Windows Core Audio API进行重定向。所用Hook回调函数为：

LRESULT CALLBACK KeyboardHookProc(int nCode,WPARAMwParam,LPARAM lParam)其中nCode为Windows系统传递给该Hook子程的消息类型，wParam和lParam为Windows系统定义参数，一般用于消息传递，在本实施例中，wParam和lParam用于判断是否需要忽略消息。服务端1在运行该应用之前，只运行该应用的列表中支持的应用（游戏、音频等），应用开始运行即表明该应用是客户端要求启动的。因此，当nCode的值为HCBT_ACTIVATE和HCBT_SETFOCUS，该Hook回调函数开始进行对Windows Core Audio API的重定向。当收到其他消息时，该回调函数不做出响应，在回调函数返回时，通过如下语句将消息传递给Hook链表中下一个Hook子程以继续捕捉系统消息。

return CallNextHookEx(g_hHook,nCode,wParam,lParam)。

（1.2）重定向模块101重定向Windows Core Audio API以使服务端1的应用调用服务端1的功能函数。

重定向模块101对Windows Core Audio API进行重定向的过程如下：

（1.2.1）重定向模块101获取Windows Core Audio API接口中函数的入口地址。

在服务端1中，Windows Core Audio API接口中函数的入口地址通过如下两种方式获取：

第一种方式：在对Windows Core Audio API接口中的函数（例如IAudioClient接口中Start、Stop、Reset、GetService、Initialize等函数）重定向之前，预先对Audio.dll进行测试加载，通过加载后的Windows CoreAudio API接口中的函数的入口地址以及动态链接库DLL中Audio.dll的入口地址获得Windows Core Audio API接口中函数（如Start、Stop、Reset、GetService、Initialize等函数）的入口地址相对于Audio.dll的入口地址的相对差值。在对Windows Core Audio API进行重定向时，通过当前Audio.dll的入口地址及所获得的所述Windows Core Audio API接口中函数的入口地址相对于Audio.dll的入口地址的相对差值，就可以获取当前所述WindowsCore Audio API接口中函数的入口地址。因此，通过这种方式就可以获取IAudioClient接口和IAudioRenderClient接口中函数的入口地址。

Audio.dll的入口地址通过如下方式获得：

HMODULE m_hCoreModule=::LoadLibrary(L"Audioses.dll");

其中m_hCoreModule的值即为Audio.dll的入口地址。

第二种方式：Windows Core Audio API的接口中函数（如IAudioClient接口的函数）的入口地址可以通过Windows Core Audio API的接口中函数的入口在接口的（如IAudioClient接口）实例的虚函数表中的偏移地址获得。

例如，IAudioClient接口的实例的地址可通过如下方式获得：

pDevice->Activate(IID_IAudioClient,CLSCTX_ALL,NULL,(void**)(IREF_GETPPTR(g_pDS,IAudioClient)));

g_pDS为指向IAudioClient实例的指针类，可以通过g_pDS的get_RefObj()接口获得g_pDS对应的IAudioClient的实例的首地址。IAudioClient中函数的入口地址可以通过函数入口在IAudioClient实例的虚函数表中的偏移地址获得。所述虚函数表中保存着IAudioClient实例的多个虚函数及每个虚函数对应实例的偏移地址。同理，通过第二种方式，也可以获取IAudioRenderClient接口中函数的入口地址。

（1.2.2）重定向模块101根据所获取Windows Core Audio API接口中函数的入口地址重定向Windows Core Audio API。

由于Windows Core Audio API接口中函数的入口地址的获取方式不同，因此，也可以采用两种方式重定向Windows Core Audio API，即使用跳转代码的方式及修改虚函数列表的方式。

第一种方式：使用跳转代码的方式。

在通过1.2.1的第一种方式获得Windows Core Audio API接口中函数的入口地址之后，即可以通过更改函数的入口地址处的汇编指令来实现函数重定向。在本实施例中，通过将Windows Core Audio API（即原始API）中函数的入口地址处的指令更改为跳转指令来实现函数重定向。

通过跳转地址dwAddr来使函数的入口地址处的指令更改为跳转指令，跳转地址dwAddr可以通过如下方式获得：

DWORD dwAddr=(DWORD)((UINT_PTR)pFuncNew-(UINT_PTR)pFunc)-sizeof(m_Jump);

其中pFuncNew为功能函数的入口地址，pFunc为Windows Core AudioAPI函数的入口地址，m_Jump为存储该跳转指令的变量。

将原始API接口中函数的入口地址处的指令修改为跳转指令后，对原始API接口中函数的访问都会被重定向到该函数对应的服务端1中的功能函数中，因此，第一种方式需要相应的还原机制，其对应的还原机制为：在修改跳转指令之前，要首先对原始API的指令（即原始指令）进行备份，在需要访问原始指令时，需要首先将备份后的原始指令写入原始API接口中函数的入口地址处，之后再进行对原始API接口中函数的访问。当需要再次重定向时，只需要再次在原始API接口中函数的入口地址处写入跳转代码即可。

第二种方式：修改虚函数列表的方式。

在C++语言中，接口的子类通过修改虚函数列表实现对接口中虚函数的具体实现，在实际使用时，子类的实例通过访问虚函数列表实现对虚函数列表中函数的调用。因此，只需要修改函数的入口在接口的实例的虚函数表中的偏移地址即可实现对函数的重定向。第二种方式对应的还原机制为：在需要访问原始API函数时，只需要访问原始API函数的入口地址即可。

类的虚函数列表位于类的地址空间的最前面，因此，通过WindowsCore Audio API接口的实例的首地址和函数在虚函数列表中的偏移地址即可获得原始API接口中函数的入口地址，修改偏移地址即可实现对原始API接口中函数的入口重定向。

修改虚函数列表的方式不会改变原始API的实现，因此，只需要访问修改前的原始API的虚函数列表中的地址，就可以实现对原始API的访问，需要注意的是，在修改虚函数列表之前，需要备份原始API的虚函数列表，以实现对原始API的访问，以及对重定向的恢复。

在本实施例中，IAudioClient接口相关的函数和IAudioRenderClient接口相关的函数采用了不同的重定向方式。其中，IAudioClient接口的相关函数通过使用跳转代码的方式实现IAudioClient中函数的重定向，IAudioRenderClient接口的相关函数采用了直接更改虚函数表的重定向方式。

在功能函数CA_GetService（CA_GetService是GetService函数对应的功能函数）实现中，输入参数riid表示所需服务接口（the interface of service）的标志值。当riid的值与IID_IAudioRenderClient相同时，就可以通过输入参数ppy访问音频流对应的IAudioRenderClient实例，进一步可以通过修改虚函数表中函数的偏移地址的方法实现对GetBuffer和ReleaseBuffer函数的重定向。

完成了重定向Windows Core Audio API后，当应用调用所述系统API时，实际上调用的是服务端1的功能函数。

（1.3）重定向模块101通过重定向后的Windows Core Audio API获取应用的音频元数据。

在对IAudioClient中的Start、Stop、Reset、Initialize函数的入口进行重定向后，即重定向模块101通过调用功能函数CA_Start、CA_Stop、CA_Reset、CA_Initialize以实现对该应用的音频的格式、码率等音频元数据的获取。

例如初始化功能函数CA_Initialize的参数与IAudioClient的Initialize函数一致，其中pFormat参数为音频流相关的元数据，pFormat为WAVEFORMATEX格式的变量，WAVEFORMATEX的定义为：

各成员变量含义如下：wFormatTag为音频的具体格式，nChannels表示音频通道数目，nSamplesPerSec表示采样频率，nAvgBytesPerSec表示音频帧的平均速率，nBlockAlign表示块对齐大小，wBitPerSample表示采样bit数，cbSize表示扩展数据区域的大小。在服务端实现中，通常情况下，音频数据格式为32位浮点数，采样频率为48kHZ，音频速率约为384000B/s。

在CA_Initialize函数中，可以通过访问pFormat变量，获得音频流相关的采样率、数据格式、数据传输速率等数据。

（1.4）重定向模块101根据应用的音频元数据捕捉该应用的音频内容。

在本实施例中，对GetService函数入口进行重定向后，即重定向模块101可调用功能函数CA_GetService，以获得运行时IAudioRenderClient实例的地址，并进一步通过对IAudioRenderClient接口中GetBuffer和ReleaseBuffer函数的入口进行重定向。

对GetBuffer和ReleaseBuffer函数重定向后，重定向模块101调用GetBuffer对应的功能函数CA_GetBuffer及ReleaseBuffer对应的功能函数CA_ReleaseBuffer实现了对应用的音频内容的获取以及缓存。

在为音频内容分配缓存空间之前，CA_GetBuffer会被调用，输入参数ppData和NumFramesRequested分别为指向缓冲区的指针以及缓冲区的大小，在音频内容写入完成后，应用会调用CA_ReleaseBuffer函数释放该缓冲区。因此CA_GetBuffer实现中，需要保存ppData指向的缓冲区的地址，等待应用写入音频内容。需要注意的是，在保存缓冲区地址之前，需要首先调用Windows Core Audio API接口中的GetBuffer函数为应用分配缓冲区，用于音频内容的实际播放。

在音频写入完成之后，CA_ReleaseBuffer函数接口会被调用，此时可以通过在CA_GetBuffer函数实现中保存的音频缓冲区地址，以及传入的已写入音频帧数，获得所述应用写入硬件的音频内容，并将该音频内容复制到服务端1的本地缓冲区中。需要注意的是在将音频内容复制到服务端1的本地的缓冲区之后，才能调用Windows Core Audio API中ReleaseBuffer函数释放缓冲区。

在功能函数实现中，需要通过与重定向方式对应的还原机制访问Windows Core Audio API以实现音频缓冲区的分配、释放和音频内容的实际回放，例如若通过第一种方式完成了重定向，那么就需要通过第一种方式对应的还原机制访问Windows Core Audio API以实现音频缓冲区的分配、释放和音频内容的实际回放。需要注意的是CA_GetBuffer和CA_ReleaseBuffer函数中调用Windows Core Audio API中的顺序，必须在分配音频缓冲区地址之后，再保存缓冲区地址，在读取音频内容之后，再释放音频缓冲区。

（1.5）重定向模块101对所捕捉到的该应用的音频内容进行缓存。

在服务端通过使用线程安全的环状缓冲区实现对应用音频内容的缓存。环状缓冲区首尾相连，通过写指针和读指针进行数据的写入和读取。使用数组来模拟环状缓冲区，通过读指针与写指针控制读取与写入的位置。在服务端1中，重定向后的windows Core Audio API会向缓冲区中写入数据，后续缓冲区中的数据会被读取进行处理，因此，缓冲区需要保证数据对多线程安全，在本实施例中，缓冲区通过Windows系统的提供的临界区机制实现数据读写操作的互斥，从而保证了数据对多线程安全。

步骤S12，处理模块102对所捕获的音频内容进行处理（调整采样率、数据表示类型）以转换为客户端2能够识别的音频数据格式。

步骤S13，发送模块103将处理后的音频内容通过网络传输给客户端2。

客户端2在与服务端1通信连接后，其处理音频内容的过程如下：

（1）建立与服务器的网络连接，接收服务端1发送的音频数据，建立音频播放器对象，基于接收到的音频数据格式对播放器对象进行初始化。

（2）启动播放器对象。

（3）向播放器中写入所接收的音频数据，此步骤重复直至网络连接断开。

通过本发明，一种基于应用虚拟化的网络实时音频传输方法，其能够通过系统API的重定向技术截获服务端应用的实时显示图像、音频数据，并经过必要的转换后发送给客户端，客户端负责图像显示与声音回放；同时客户端接收到用户的操作输入后，通过网络传输给服务端的应用进行应用操控，并引起该应用的显示变化与音频播放，上述过程周而复始，从而达到客户端远程操控服务端应用的效果。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。

Claims (10)

1.一种基于应用虚拟化的网络实时音频传输方法，应用于服务端，其特征在于，该方法包括：

重定向步骤，当用户在客户端上要使用服务端上的应用时，利用服务端的应用层声音捕捉装置实时捕捉服务端的所述应用产生的音频内容；

处理步骤，对所捕获的音频内容进行处理以转换为客户端能够识别的音频数据格式；

发送步骤，将处理后的音频内容通过网络传输给客户端。

2.如权利要求1所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，所述重定向步骤包括：

（a）通过Hook子程捕捉服务端上的所述应用的消息；

（b）重定向Windows Core Audio API以使服务端的所述应用调用服务端的功能函数；

（c）通过重定向后的Windows Core Audio API获取所述应用的音频元数据；

（d）根据所述应用的音频元数据捕捉所述应用的音频内容；

（e）对所捕捉到的所述应用的音频内容进行缓存。

3.如权利要求2所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，所述步骤b包括：

（b1）获取Windows Core Audio API接口中函数的入口地址;

（b2）根据所获取Windows Core Audio API接口中函数的入口地址重定向Windows Core Audio API。

4.如权利要求2所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，所述功能函数与Windows Core Audio API接口中函数的特征保持一致，所述功能函数用于替换服务端中Windows CoreAudio API接口中的函数，用以通过功能函数捕捉服务端对WindowsCore Audio API的调用，从而获取所述应用写入服务端的硬件的音频数据。

5.如权利要求3所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，步骤b1包括：

在对Windows Core Audio API接口中的函数重定向之前，预先对Audio.dll进行测试加载；

通过加载后的Windows Core Audio API接口中的函数的入口地址以及动态链接库DLL中Audio.dll的入口地址获得Windows CoreAudio API接口中函数的入口地址相对于Audio.dll的入口地址的相对差值。

6.如权利要求3所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，步骤b1包括：

通过Windows Core Audio API接口中的函数的入口在接口的实例的虚函数表中的偏移地址获得Windows Core Audio API接口中函数的入口地址。

7.如权利要求5所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，在步骤b2中通过跳转地址将Windows Core Audio API接口中函数的入口地址处的指令更改为跳转指令来实现函数重定向。

8.如权利要求6所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，在步骤b2中通过修改Windows Core Audio API接口中函数的入口在接口的实例的虚函数表中的偏移地址实现对函数的重定向。

9.如权利要求2所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，通过调用功能函数CA_Start、CA_Stop、CA_Reset、CA_Initialize获取所述应用的音频的格式、码率的音频元数据。

10.如权利要求2所述的基于应用虚拟化的网络实时音频传输方法，其特征在于，通过调用GetBuffer对应的功能函数CA_GetBuffer及ReleaseBuffer对应的功能函数CA_ReleaseBuffer实现对应用的音频内容的获取以及缓存。

Images