[0035]可以理解的是，如果发言者仅有一个，则不需要转发音频数据给该发言者对应的接收方。
[0036]S32:如果所述当前角色是听众，获取发言者的解码后的音频数据，并对所述解码后的音频数据进行混音处理，以及对混音处理后的音频数据进行编码处理，得到编码后的音频数据，并将所述编码后的音频数据确定为要转发的音频数据。
[0037]例如，参见图2，如果发言者包括:A，B，C，听众是D和E，则对应D和E，获取A，B和C的解码后的音频数据，对该解码后的音频数据进行混音处理，再对混音后的音频数据进行编码处理，之后将编码处理后的音频数据分别发送给D和E。
[0038]通过根据角色的不同，采用不同的手段得到要转发的数据，可以尽量降低CPU消耗以及网络流量开销。
[0039]另外，如图2所示，当听众的个数为多个时，可以不需要对应每个听众设置一个编码器，而由同一个编码器对混音处理后的音频数据进行编码处理。例如，参见图2，对应D和E，都由同一个编码器(conf Encoder)进行编码处理。
[0040]通过采用同一个编码器对应不同听众进行处理，可以相对于Full-transcoding模式，减少编码器的数量，由于CPU的开销主要是由编码器引起的，因此可以降低CPU开销。
[0041]进一步的，考虑到发言者可能不具有多路解码能力，此时，可以类似Full-transcoding的处理流程，即对其他发言者的解码后的音频数据进行混音以及编码后得到要转发的音频数据。
[0042]例如，参见图4，如果所述当前角色是发言者，且其他发言者的个数是多个时，确定要转发的音频数据的具体流程可以包括:
[0043]S41:确定所述发言者是否具有多路解码能力。
[0044]其中，服务器可以与发言者进行预设格式的信令交互，通过信令交互获知发言者是否具有多路解码能力。例如，服务器向A发送查询信令，查询信令用于查询A是否具有多路解码能力，A接收到该信令后，获取自身的能力，如果具有多路解码能力，则向服务器反馈具有多路解码能力的反馈信令，反之反馈不具有多路解码能力的反馈信令。而具体的查询信令以及反馈信令的格式可以是预先规定的，例如，某个字段用特定值表示查询信令，某个字段用I或O表示具有或不具有多路解码能力。
[0045]S42:在具有多路解码能力时，获取除自身之外的其他发言者的解码前的音频数据，并将所述解码前的音频数据打包后确定为要转发的音频数据。
[0046]该步骤的具体内容可以参见S31，在此不再赘述。
[0047]S43:在不具有多路解码能力时，获取出自身之外的其他发言者的解码后的音频数据，并对所述解码后的音频数据进行混音，以及对混音后的音频数据进行编码，将编码后的音频数据确定为要转发的音频数据。
[0048]例如，A是发目者，但A不具有多路解码能力，则可以获取B和C的解码后的音频数据，对B和C的解码后的音频数据进行混音处理，再对混音处理后的音频数据进行编码处理，将编码处理后的音频数据确定为转发给A的音频数据。
[0049]通过检测多路解码能力，可以很好解决具有或不具有多路解码能力的终端同时接入会议的兼容性问题。
[0050]另一实施例中，还可以对发言者的数量进行限制，以获取更优良的收听效果。参见图5，该方法还可以包括:
[0051]S51:检测发言者的数量，并在该数量超过预设个数时，从检测到的发言者中选择出预设个数的发言者。
[0052]之后，在根据当前角色获取要转发的音频数据时，采用的发言者的解码前或解码后的音频数据时，该采用的发言者是指选择出的预设个数的发言者。
[0053]可选的，预设个数可以是3个或者2个。
[0054]以3个为例，假设检测到的发言者是4个，则可以根据音频特性，例如每个音频数据的能量值，选择能量值较大的3个音频数据对应的发言者作为选择出的发言者。
[0055]S13:将所述要转发的音频数据，发送给所述作为接收方的终端。
[0056]该步骤可以由服务器内的发送模块执行。参见图2，作为接收方的终端用23表示。
[0057]具体的，当发言者是A，B，C，且接收方都具有多路解码能力时，将B的解码前的音频数据和C的解码前的音频数据打包(B+C packet)后发送给A，将A的解码前的音频数据和C的解码前的音频数据打包(A+C packet)后发送给B，将A的解码前的音频数据和B的解码前的音频数据打包(A+B packet)后发送给C。
[0058]而对于听众D，E，是将A的解码后的音频数据，B的解码后的音频数据，以及C的解码后的音频数据进行混音，得到混音后的音频数据(A+B+C PCM)，再对混音后的音频数据进行编码(由conf Encoder进行编码)，得到编码后的音频数据，将该编码后的音频数据发送给D和E。
[0059]需要说明的是，图2中的作为接收方的D和E中虽然标识了多个解码器(Decoder)，但是，对于当前作为听众的角色，该D和E只需要一个解码器就可以，多个解码器可以在D和E作为发言者时采用。
[0060]本实施例中，通过获取解码前的音频数据和解码后的音频数据，并根据当前角色的不同，采用不同的方式获取要转发的音频数据，可以兼顾Full-transcoding模式和relay模式的优点，尽量降低CPU消耗和网络流量消耗。具体的，现有技术一需要对应每个终端设置编码器，而本实施例可以只设置一个编码器，由于编码器占用较大的CPU开销，因此，本实施例可以解决音频通讯系统运营级别架构服务器(Server)的CPU成本问题，显著提升单CPU的并发处理能力。由于大部分终端处于听众状态，对听众对应的音频数据进行编码，而不是直接转发多路音频数据，可以降低绝大部分与会终端的网络流量。通过Server的优化取得CPU消耗和网络流量的平衡，即在有效降低CPU消耗情况下，同时也降低了 Server和终端(Client)的1网络流量。
[0061]图6是本发明另一实施例提出的音频数据处理装置的结构示意图，该装置可以是指服务器，该装置60包括:
[0062]接收及解码模块61，用于接收作为发送方的终端发送的解码前的音频数据，以及，对所述解码前的音频数据进行解码，得到解码后的音频数据；
[0063]参见图2，假设终端分别用A，B，C，D，E表示，终端可以发送音频数据，也可以接收音频数据，其中，作为发送方时用终端21表示。
[0064]在服务器22内，对应每个发送方，分别设置接收模块(Recv)和解码模块(Dec)，接收模块用于接收发送方发送的音频数据，该音频数据是解码前的音频数据，解码模块用于对接收的音频数据进行解码，得到解码后的音频数据。如图2所示，经过接收模块和解码模块，对应每个发送方可以得到两种数据，分别是解码前的音频数据和解码后的音频数据，在图2中，两种数据分别用不同的填充方式表示。
[0065]获取模块62，用于确定作为接收方的终端的当前角色，如果当前角色是发言者，根据所述解码前的音频数据获取要转发的音频数据，或者，如果当前角色是听众，根据所述解码后的音频数据获取要转发的音频数据；
[0066]当前角色可以包括:发言者，或者，听众。
[0067]可以理解的是，在不同的时刻，发言者或者听众是可以切换的。
[0068]根据当前角色的不同，可以采用不同的处理方式得到要转发的音频数据。例如，对于发言者，可以将其他发