記憶違いではなく、単に古い世代なだけです 
この機能は、Mumble自体が10年以上経過していた10年前のMumble 1.3で追加されました。
長年にわたり、Mumbleに対する主な不満点の一つでした。
「いいね！」 5
さっきちょっと試してみたら、めちゃくちゃかっこいいですね！ 初期のフィードバックをいくつか共有させてください。
- スクリーンシェアと音声の音量について:
試してみたのですが、他の参加者のスクリーンシェアの音量を、その人の話し声の音量と別に表示するオプションはありませんでした。 音声とスクリーンシェアのオーディオの両方を扱う、統合されたスライダーが1つしか表示されません。 スライダーを見落としませんでしたか？ それとも私の理解が間違っていますか？ （私のユースケースは、誰かのゲーム配信の音量をミュートまたは下げる一方で、その人の話し声は聞けるようにしたいということです。）
- 小さなバグ: 部屋を編集したとき（例: 部屋名の先頭文字を大文字にするなど）、再度編集に戻ると、ページ全体をリロードするまで編集オプションが表示されません。 編集を適用した後、クライアントUIが自分には権限があることを忘れているのかもしれません。
- IPプライバシーに関するポップアップには本当に感謝しています！ この懸念を先回りして対応してくれてありがとうございます
- 私のシステムでは、マイクが非常に小さく、かなりのブーストが必要です。 これは私の環境側の問題ですが、Mumble（そしてDiscordもそうだと思いますが、しばらく使っていないので覚えていません）では、これを克服するために多くの手動ゲインを適用できます。 オートゲイン機能を無効にした場合、ブーストするための大きなヘッドルームを持つ手動ゲインノブを提供することを提案します（私の通常の生のバックグラウンドノイズは-48db、話し声は約-30dbです。 Audacityでは、通常の範囲に上げるために約20dbのブーストが必要です。）
- Discourseの問題ではありませんが、すべてのLinux Webrtcスクリーンシェアと同じ制限があります。 つまり、Firefoxではオーディオ付きスクリーンシェアが不可、Chromeではブラウザタブのオーディオスクリーンシェアのみサポート、ということです。 つまり、ゲームをストリーミングしたい場合、ブラウザの制限によりLinuxではゲームのオーディオをストリーミングできません。
- 他のソリューションで見た巧妙なワークアラウンドは、OBSを向けることができるエンドポイントアドレスを公開することでした。（おそらくLivekitはすでにこれをサポートしていますが、まだLivekitサーバー部分をセットアップしていないので確認できていません）
- 字幕機能に本当に感動しました！ 文字起こし部分はまだユースケースがありませんが、ビジネス環境でのノート-taking（議事録作成）などで非常に有用だと確実に想像できます。
- 現在、チャットルームに人がいることを訪問者が気づくためのUI上の課題があります。 スクロールしないと見えないためです – 場合によってはかなり長い距離です。 私のインストール環境では、リンク/カテゴリ/タグが多いため、1ページ分以上スクロールする必要があります。 これはモバイルでは特に顕著で、メニューバーをクリックしない限り、チャットユーザーリストが全く表示されません。 チャットがアクティブなときのために、右上に何らかのボタンを設置することを提案します（Mumbleからの例）。 そこに**(1)**以上が表示されているのを見るのが、誰かがチャットに参加してほしいという私の主な合図です！
とにかく、素晴らしい仕事です – これはDiscourseにとって大きな前進であり、非常に期待しています！ 
「いいね！」 6
多くの素晴らしいフィードバックをいただいています。その中で特に注目すべき点を強調しておきます。
これまでは私の主な課題であり、プラットフォームをまたいで起きている問題です。ブラウザにはハードウェアエンコード機能がなく、7680x2160@240Hzのゲーミングセッションをストリーミングすることは不可能だからです。
そこで、ネイティブのデスクトップアプリを通じてこれに対応し、グローバルPTTなどの機能を実装することで、これらの統合をより適切に処理できないか検討しています。
「いいね！」 6
ありがとうございます。ネイティブのデスクトップアプリは魅力的に聞こえますが、既存のオープンなストリーミング標準にも対応してほしいです。少なくとも私の友人グループでは、全員がすでにOBSをインストールしており、信頼しており、どこに向けて配信すればいいか分かっています。（正直に言えば、これはゲーマーの間ではよくあることですが、技術に疎い他のユーザーにはあまり見られない傾向です）
「いいね！」 1
ある意味では同意します。つまり、Zoomとは違うということです。しかし、OBSは幸いなことに多くの分野で標準として使われているため、少しだけ異論を唱えさせてください。
「いいね！」 1
今日、リビルド中に小さなトラブルがありました。その原因は、以前プラグインを「Resenha」という名前でテストしていたことです。ちなみに、名前が「Voice」に変更されたとき、かなり悲しくなりました。
この方法で問題が解決しました：
「いいね！」 2
さて、プラグイン本体についてですが、気づいたことがあります。おそらく、300コミット以上を含むほぼ2週間ぶりのリビルドの影響で、私の錯覚にすぎないのかもしれませんが、自分のインスタンスでボイス機能のテストを行った際、トグルが「オフライン」に設定されていたにもかかわらず、#quem-está-online に表示されてしまいました。これは想定通りの動作ですか？
これはまもなく修正されるはずです：FIX: Do not overwrite permissions after editing - Pull Request #43496 - discourse/discourse - GitHub
「いいね！」 3
ホスティング > 概要ページ > サイトアクティビティ（例）のセクションに、「過去7日間のボイスチャット（例）5件」のような情報を表示することは可能でしょうか？
あるいは、適切な表現で表示する方法はありますか？
私たちの利用目的は、新しいメンバーに参加してもらうために、できるだけ多くのアクティビティを示すことです。
「いいね！」 4
個人ユーザーではなく、グループ単位でボイスルームに招待することはできますか？その場合、グループにまだ残っているメンバーを削除する必要があると、メンバーページがややこしくなることは承知しています。
現在進行中のアクティブな顧客向けプロジェクトでこれを導入する予定ですが、グループが17個あり、それぞれに異なるメンバーが含まれているため、対応が少し大変です 
ええ、それが基本的にこの仕組みがこうなっている理由です。
この17のグループのメンバーに機能を限定したい場合は、サイト設定を通じて実現できますが、ワンタイム招待はユーザー単位で管理されています（スパムの増幅になりやすいため）。また、ルームへの参加自体もユーザー単位で管理されており、グループとの同期を維持することは将来の改善事項です。
「いいね！」 4
まったくその通りですね。API経由でもこれを実現する方法はないようです 
招待リンクのやり方について、何か見落としはありますか？承認済みグループに属するテストアカウントにリンクを共有しましたが、テストユーザーでクリックすると Oops! That page doesn’t exist or is private というエラーが表示されます。
追記：そのユーザーを招待してサイドバーにボイスチャンネルが表示されても、リンクをクリックするとやはりそのOopsページに飛ばされてしまいます。
「いいね！」 1
プライベートカテゴリに関連付けられている場合、チャットチャンネルへのメンバーの追加と削除に関する一部のロジックはすでに処理しています。
Falco、ボイスチャンネルをチャットチャンネルに関連付ける方法がすでに存在するかどうか、覚えていません。DMについては以前に議論したことがあると思います。しかし、今回のアプローチとして検討する価値があるかもしれません。
あるいは、チャットチャンネルで行っていることを模倣し、カテゴリをアクセス制御のレイヤーとして機能させることもできます（ただし、この間接的なレイヤーを削除し、チャンネルレベルで直接アクセス権を設定できるようにするべきという議論をこれまで何度もしてきました）。
- プライベートカテゴリを作成する
- そのカテゴリにチャットチャンネルを作成する
- そのチャットチャンネルでボイスを有効にする（または、そのカテゴリにボイスチャンネルも作成する）
また、この機能全体を特定のグループセットに制限したい場合は、サイト設定を介して管理する必要があると考えます。ワークフローを活用することで、ある程度の自動化や整合性チェックが可能になるかもしれません。
@martin これは、あなたが取り組んでいる一般的なアクセス制御の仕組みと重複する部分があるかもしれません。
@awesomerobot と連携し、これをより広く推進する動きを早めに始める価値があるかもしれません。そうすることで、この側面をアプリ全体にわたってより一貫して適用する方法を検討できます。
「いいね！」 1
それは奇妙ですね。それらのテストユーザーは、アクセスを許可しないような信頼レベルに設定されているのでしょうか？
はい、それはロードマップに載っています。
リリースの妨げになるものではありませんし、アプリのこの部分は非常に複雑なので、オーディオとビデオのコア部分を正しく実装する方にリソースを集中させた方が効果的ですが、今後数ヶ月でフォローアップする予定です。
「いいね！」 5
devに返信しましたが、この用途には従来の複雑なカテゴリ別の権限継承よりも、新しいACLシステムの方が適していると思います
「いいね！」 2
そうではないと思う。私のテストユーザーをTL3に引き上げただけなので、TLによる制限が原因であることは絶対にない。招待リンク自体に何かが壊れているようだ。通常の手段でアクセスした場合の状況は以下を参照（ユーザーにアクセス権があるかどうかに関わらず、リンクの挙動は同じ）。
残念ながら、これらのグループはDMのみを介して動作するため、カテゴリごとの紐付けに頼ることはできない。
なぜ動作しないのかを突き止めれば、DMで招待リンクを共有するだけで十分だろうと思う
「いいね！」 1
ルームタイプが「オープン」に設定されているボイスルームに参加するたびに、ユーザーのマイクが自動的にオンになることに気づきました。ステージ型のボイスルームでスピーカーが参加した場合も同じことが起きます。管理者が、参加時にマイクを自動的にオンにするかどうかを設定できるようにすることは可能でしょうか。
「いいね！」 1
それは混乱を招きませんか？
Zoom、Teams、Meetなどの「ワーク」系ミーティングアプリでは、参加者の数が一定の閾値を超えるとこの挙動が発生しますが、私たちが参考にしているTeamSpeak、Ventrillo、Mumble、Discordなどのアプリ群には、もともとこのような挙動はありませんでした。
この追加ステップは、先行事例がほとんどなく、初心者にとってUXをさらに複雑にする余計な手順に感じます。
「いいね！」 2