【问题标题】:How to handle audio streams and mixing for VoIP如何处理 VoIP 的音频流和混合
【发布时间】:2013-08-25 18:10:22
【问题描述】:

我们正在开发基于 Java 的 IP 语音程序,我们需要找到一种有效的方法来将流和服务器端的压力保持在合理的水平。我们正在为多人游戏编写这个,我们计划有几种不同的模式来确定如何混合和发送音频。如果他们选择不参与语音聊天,我们计划让它“选择加入”以将无用的流排除在外。除此之外,我们还在考虑频道、私人聊天(2 人)和邻近度。如果我们使用一个有 16 人以上的频道,我们想找出是否有办法避免 x^2 的流数(在本例中为 256)。我们还需要尝试将客户端工作保持在合理的水平,因为它将运行游戏。我们不太确定大型服务器可以处理多少工作,因为随着频道中的人越来越多,它将成倍增长。我们可能需要限制每个频道的人数,或者允许服务器所有者这样做,以及限制频道的数量。根据受欢迎程度,这款游戏可以同时在服务器上容纳大约 40-500 人,我们不确定如何处理服务器处理和带宽上的这种压力。

本质上,我们是在询问是否有人对现有系统有任何了解,这些系统可以有效地处理此问题。如果有任何相关性,我们将使用 JSpeex 进行音频编码。那么,是否有任何方法可以处理这个问题,或者甚至可能来自社区的一些想法?我们还计划在我们一直在开发的类似 Skype 的小规模程序中重新实现这一点。

【问题讨论】:

    标签: java audio bandwidth mixing


    【解决方案1】:

    我不明白您为什么需要 256 个流。你不应该直接从一个客户到另一个客户。

    对于每个客户端,您需要一个与服务器的双向连接。所有输入/输出音频都通过服务器定向。然后,服务器将播放器要接收的所有音频多路复用到单个音频流中并一起转发。

    当你在私聊时,服务器只转发与你私聊的其他玩家的数据包。

    当使用接近时,服务器将来自范围内任何播放器的音频多路复用到单个流中。

    我认为任何体面的音频编码包都支持从多个通道多路复用音频,但我对 JSpeex 一无所知。

    【讨论】:

    • 256 个流通过服务器传输。 x^2 个流,因为我们需要将音频分发给每个人,来自每个人,不包括您自己的音频(回声)。如果我们有办法在返回时“静音”他们自己的音频,我们只需要 x 个流。它是一种混合类型的东西,我们不确定如何处理它。
    • 这就是我要说的。您不需要来自/到每个人的单独流。您只需要服务器将每个人的输入多路复用在一起。所以每个用户只需要一个输入和一个输出通道。服务器只需要聪明。它显然不会包含任何回声音频。
    • 我们计划每个客户端只有一个套接字连接。我们纯粹是在谈论服务器处理中的流。不确定我是否遗漏了什么,但发送到每个客户端的输出将被多路复用。如果我完全遗漏了什么,我深表歉意。
    • 正确,但每个播放器应该只有一个输出流,每个播放器只有一个输入流。服务器应该将音频组合成每个客户端唯一的单个流,然后转发它。
    • 正是我的观点。这意味着,我们需要拆分输入流,并为每个连接的人相应地分配它们。 16 人连接意味着 16 进 16 出,但我们需要创建副本以创建每个用户的输出流。意思是,服务器上的 x^2 个流。如果有一种方法可以在混合之前不进行复制,我很想知道。
    猜你喜欢
    • 2014-06-04
    • 1970-01-01
    • 2021-02-13
    • 2015-02-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多