没记错，只是老派了点 
这个功能直到 10 年前 Mumble 1.3 版本才加入，而那时 Mumble 本身已经发布超过 10 年了。
长期以来，这是大家抱怨 Mumble 的主要问题之一。
5 个赞
我刚试玩了一下，真的太酷了！想给一些初步的反馈。
- 屏幕共享与语音的音量控制：
我试了一下，但并没有看到将其他参与者的屏幕共享音量与语音音量分开显示的选项。它只显示了一个合并的滑块，同时控制他们的语音和屏幕共享音频。是我漏掉了某个滑块，还是我理解错了？（我的使用场景是：能够静音或降低某人游戏直播的音量，但仍然能听到他们说话。）
- 一个小 Bug：当编辑房间时（例如将房间名称的首字母大写），当我返回再次编辑时，除非刷新整个页面，否则不会显示任何编辑选项。也许客户端 UI 在应用编辑后忘记了我拥有权限。
- 我非常感激 IP 隐私弹窗！感谢你们预见到这个问题
- 在我的系统上，我的麦克风非常安静，需要大量的增益。这是我这边的系统问题，但在 Mumble 中（我假设 Discord 也是如此，但已经很久没用了，所以我不太记得了）我可以应用大量的手动增益来克服这个问题。我建议，在禁用自动增益选项时，提供一个手动增益旋钮，并留出大量的余量用于提升音量（我正常的原始背景噪音是 -48db，语音大约是 -30db。在 Audacity 中，这大约需要 20db 的增益才能达到正常范围。）
- 这不是 Discourse 的问题，但它具有所有 Linux WebRTC 屏幕共享的相同限制——即 Firefox 不支持音频屏幕共享，而 Chrome 仅支持浏览器标签页的音频屏幕共享。因此，如果我想直播游戏，由于浏览器的限制，我无法在 Linux 上直播游戏音频。
- 我看到另一个解决方案提供的巧妙变通方法是：只需暴露一个端点地址，我可以将其指向 OBS。（也许 LiveKit 已经支持这个功能，我还没有设置 LiveKit 服务器部分）
- 我对字幕功能印象深刻！我目前还没有转录部分的使用场景，但我肯定能看到它在商业环境中用于做笔记时非常有用。
- 目前存在一个 UI 挑战：访客不知道聊天室里有人，除非他们向下滚动——可能是一段很长的距离。在我的安装中，由于我所有的链接/类别/标签，滚动距离超过一整页。在移动设备上尤其如此，除非点击菜单栏，否则根本不会显示聊天用户列表。我可能会建议当聊天处于活动状态时，在右上角添加一个按钮（Mumble 的示例）。看到里面有 (1) 或更多消息，总是我意识到有人想让我加入聊天的主要信号！
总之，这项工作做得很棒——这对 Discourse 来说是一个巨大的进步，我非常期待！
6 个赞
收到了很多很棒的反馈，只是想强调一下这一点
这一直是我面临的主要挑战，而且它跨越了多个平台。因为浏览器缺乏硬件编码支持，所以通过浏览器以 7680x2160@240Hz 的分辨率直播我的游戏会话是不可能的。
因此，我正在探索通过原生桌面应用程序来处理这一问题，以及诸如全局 PTT（推键说话）等功能，以便我们能更好地处理这些集成。
6 个赞
谢谢；原生桌面应用听起来确实很有吸引力，但请也支持现有的开放流媒体标准，因为至少在我的朋友圈子里，大家都已经安装了 OBS，信任它，并且知道如何配置它的输出地址。（当然，这种情况在玩家群体中比在其他不太懂技术的用户中更为普遍）
（编辑——为了澄清一下，原生应用听起来也很酷。如果能把所有论坛整合到一个界面里，那会非常方便。）
1 个赞
从某种意义上说，我同意你的观点，意思是它并不是 Zoom。但我也允许自己稍微持不同意见，因为幸运的是，OBS 是许多领域都在使用的标准！
1 个赞
今天在重建时遇到了一点小麻烦，因为我之前用“Resenha”这个名字测试过这个插件。顺便说一句，当它改成“Voice”时，我其实挺难过的。
这里的方法解决了我的问题：
2 个赞
现在说说插件本身，我注意到了一点——也许只是因为我在将近两周、超过 300 次提交之后重新构建，才产生的错觉，但当我在实例上测试语音功能时，即使开关设置为“离线”，我仍然会显示在 #quem-está-online 中。这是预期行为吗？
这应该很快就会修复：FIX: Do not overwrite permissions after editing - Pull Request #43496 - discourse/discourse - GitHub
3 个赞
是否可以在我们的 hosted>about 页面>site activity（例如）中显示最近 7 天内的 5 次语音聊天？或者使用其他合适的措辞？
我们的使用场景是展示尽可能多的活动，以帮助吸引新成员加入。
3 个赞
能否邀请整个群组加入语音房间，而不是逐个邀请用户？我理解，如果群组中有人需要被移除，在成员页面处理起来会很麻烦。
我们打算把这个功能应用到几个正在进行中的、面向客户的活跃项目中，但涉及 17 个群组，每个群组的人员构成都各不相同 
是的，这基本上就是它这样运作的原因。
如果你想将整个功能限制在那 17 个组的成员范围内，可以通过站点设置来实现，但一次性邀请是针对每个用户的（否则太容易变成垃圾信息放大器），而房间成员资格本身也是针对每个用户的（使其与组保持同步将是未来的改进方向）。
3 个赞
完全合理。看起来通过 API 也没法实现这一点 
我是不是漏掉了什么关于邀请链接方法的问题？我把链接分享给了一个属于已批准分组的测试账户，但当我用测试用户点击该链接时，却收到了 Oops! That page doesn’t exist or is private 的提示。
更新：天哪，即使我邀请了该用户，并且在侧边栏看到了语音频道，点击链接后还是会跳转到那个 Oops 页面。
1 个赞
如果频道与私有分类相关联，我们已经处理了其中一些添加和移除聊天频道人员的逻辑。
Falco，我不记得我们是否已经有方法将语音频道与聊天频道关联起来。我知道我们过去在讨论私信（DMs）时提到过这一点。但这可能是一个可行的方案。
或者，我们可以参考我们在聊天频道中的做法，让分类充当访问控制层（尽管我们经常讨论过移除这种间接层，并允许直接在频道级别设置访问权限）。
- 设置一个私有分类
- 为该分类创建一个聊天频道
- 在该聊天频道中启用语音功能（或者也为该分类创建一个语音频道）
如果你还想将整体功能限制在一组特定的群组中，我认为这仍然需要通过站点设置来管理。也许工作流（Workflow）可以帮助实现一定程度的自动化或一致性检查。
@martin 这可能与你在做的通用访问控制功能有一些重叠。
也许值得与 @awesomerobot 沟通一下，看看是否近期可以就这方面进行更广泛的推进，以便我们可以思考如何更一致地在全应用中应用这一方面。
这有点奇怪，这些测试用户是不是处于某种特殊状态，比如信任等级不够，导致无法访问？
没错，这已经在我们的路线图上了。
这绝对不是发布版本的阻碍因素，而且这部分应用逻辑非常复杂，我们的精力或许能更好地用在确保音频和视频核心功能的正确性上，但我会在接下来的几个月里跟进这件事。
4 个赞
我在开发版上回复过了，不过新的 ACL 系统应该很适合这个场景，比旧的那套按类别继承权限的复杂机制要好用多了
2 个赞
我不这么认为。我刚把我的测试用户提升到了 TL3，所以肯定不是信任等级的限制。邀请链接本身似乎出了问题。请看下面通过正常方式访问时的情况（无论我的用户是否有访问权限，链接的表现都是一样的）。
不幸的是，这些群组仅通过私信（DM）运作，因此没有基于分类的关联关系可以依赖。
我想，一旦我们弄清楚为什么它不起作用，在私信中分享邀请链接就足够了
1 个赞
我注意到，每次加入房间类型设置为“开放”的语音房间时，用户的麦克风都会自动开启。当说话者加入舞台语音房间时，也会出现同样的情况。我想知道是否可以让管理员设置用户在加入时是否自动开启麦克风。
1 个赞
这不会让人困惑吗？
像 Zoom、Teams、Meet 这类“工作”风格的会议应用，在参会人数超过一定阈值时会出现这种行为，但我们所借鉴的那类应用（如 TeamSpeak、Ventrillo、Mumble、Discord 等）从未有过这样的设计。
我觉得这个额外的步骤缺乏先例，反而给新手增加了不必要的复杂性，让用户体验更加繁琐。
2 个赞