実際には、私が参加しているフォーラムのユーザーの多くは、外部環境で会話をしています。そのため、マイクをオンにしたまま直接参加すると、周囲の雑音が通信を妨げてしまうことがあります。また、もう一つバグがあります。ボイスページでマイクをミュートするようクリックしても、実際にはマイクがオンになったままになることがあり、本当にオフにするには一度オフにしてから再度オンにする必要があります。
Jitsiと比較すると、いくつかの違いがあります。Jitsiには、ボイスチャットに正式に参加する前に、マイクをミュートするかミュートを解除するかを選択できるインターフェースがありますが、Discourse Voiceにはこれがありません。このインターフェースがあることで、この問題は大きく回避できると思います。
なるほど、分かりました。そうしたユーザーはPTT（プッシュ・トゥ・トーキー）の恩恵を受けるでしょうか。当社はPTTの基本的なサポートを提供していますが、モバイルおよびデスクトップの両方でより優れたPTT体験を実現するには、ネイティブアプリが必要になる傾向があり、この分野は現在積極的に検討を進めています。
about>activityにボイス統計を追加してくれた皆の尽力に感謝します:clap:
他に何か推測はありますか？別のデモユーザーを招待してみましたが、残念ながらまだ動作していません。リンク経由でユーザーを正常に招待することができましたか？
追記：先ほど、新しいルームの管理者に招待を送信しましたが、やはり404ページが表示されました。
今は休暇中で、この件を確認する時間が取れていません。来月初めに戻ります。
楽しい休暇を @Falco さん！よく休んで、Discourse に元気に戻ってきてください 
@putty サイト上のユーザー名に関連する問題かもしれません。スクリーンレコーディング内のルートは /invited-by/derek.putnam で終わっていますが、現在のこのルートはユーザー名にピリオド（.）を含むことを拒否しています。この問題は以下のPRで修正されるはずです：
また、/invited-by/... の部分を省いてリンクを共有することで、自分のサイト上でテストすることもできます。
週末にこれを試してみたら、かなり効果がありました 
発見したバグ（あるいは意図しない機能）は、このシステムがステレオマイクに対応している点です。通常、Web会議ソフトでは、この種の音声をキャプチャするのにモノラルマイクハードウェアが一般的に使われるため、左チャンネルと右チャンネルはモノラルにダウンミックスされます（これにより帯域幅の消費も理論上は減ります）。現在のDiscourseのソリューションでは、ステレオマイクがそのまま送信されます。
しかし、一部のマイクは1つのチャンネルにのみ出力し、もう一方のチャンネルを空にしたままにすることがあります（これは複数の入力を持つプロコンシューマー向けオーディオインターフェースでは特に一般的かもしれませんが、安価なマイクでも同じようなことが起こるかもしれません）。これにより、リスナーはそのスピーカーを左耳または右耳のどちらか一方からしか聞けなくなります。実は私自身もこれに気づいていませんでしたが、どうやらMumble、Discord、Nextcloud、Jitsi、ゲームなどはすべてモノラルにダウンミックスしているようです。
そのため、マイクの音声ストリーム（スクリーン共有の音声ストリームとは別のチャンネルセットであるべきもの）をデフォルトでモノラルにダウンミックスすることを推奨します。一般的に言って、通話中に広い視野で音声をキャプチャしたいとユーザーが本当に望む状況は少ないでしょう——音楽バンドがファンに向けてストリーミングを行う場合などが考えられますが。その場合、ユーザーが意図的にワイドフィールドステレオマイクを使用したい場合は、設定からそれを有効にしてモノラルダウンミックスを無効にできるようにすればよいと思います。
間違いがなければ、最大以外のすべてのオーディオ品質でダウンミックスが行われます。高品質または標準に下げて試してもらえますか？
情報ありがとうございます。次回試してみますが、ビットレートを下げることなく、これを個別に切り替えられる方がより理想的です。
音声ルームを数週間前から、グループサイズを制限（最大5名）して利用しています。現時点ではすべて問題なく動作しています。おめでとうございます！技術的なバックエンドをDiscourseのWebアプリやデータベースから分離したいと考えています。Docker ComposeでLiveKitサーバーを設定する方法に関する良いドキュメントはありますか？（Claudeに聞く前に 
）
大好き 
そうだったんですね！
なぜそうしたいのか、もう少し詳しく教えていただけますか？
デフォルトの設定でも、LiveKitの設定でも、Discourseが担う責任の量は同じです。Meshは良いデフォルトオプションなので、それがうまくいっているなら、それを超えるまで使い続けることをお勧めします。
@Falco さん、ありがとうございます。何も変更しなくて済むなら、それがさらに良いですね。それでは、私たちのインスタンスではすべてのコミュニティに対してこの機能を開放しますが、1ルームあたりの人数は5人に制限します。ほとんどのアドホックな会議では、これで十分だと思います。
プライバシーに関する注意：将来（おそらく「Voice room」プロジェクトのより後の段階で）、完全なGDPR適合性のための文書化されたソリューションが必要になります。現在、デフォルトとして stun.l.google.com と global.stun.twilio.com が使用されています。これらはどちらも米国に拠点を置くため、米国のクラウド法に従わなければならず、これは欧州の管轄権と矛盾しています。
すでに回答されている場合は申し訳ありません。
OP（スレッド作成者）の告知では、ルーム権限の下に「公開、グループ制限付き、非公開ルーム」が記載されていますが、ルームにグループ制限を設定する場所が見つかりません。
私の使用ケースは、特定の1つのグループのメンバーのみが見えて参加できるルームです。基本的にカテゴリのようなものです。voice_allowed_groups と voice_create_room_allowed_groups の設定はサイト全体に適用されるため、ここで必要としている内容はカバーされていません。
ルームエディターには、Public トグルとユーザーごとのメンバー管理しか表示されません。
ルームごとのグループ制限は実装されていますか？もしそうであれば、その設定はどこにありますか？実装されていない場合、予定されていますか？テストをお手伝いできます。
@mcwumbly が上記でこの件について少し議論していました Voice: Discord-style voice and video rooms, now bundled with Discourse 🎙 - #55 by mcwumbly 。Chat、カテゴリ、Voice の間で、グループによるアクセス設定の実現方法により一貫性があるとなれば、それは確かに素晴らしいことです。
私のコミュニティの多くにおいて、カテゴリ、Chat、Voice は、あるグループが独占的に利用したいリソースとなります。そのため、グループによるアクセス制御が可能であることは、私の優先事項の上位にあります。
まだ実装されていません。現在はすべてユーザーベースです。
@mcwumbly が言及した通り、チャットルームやボイスルームなどの機能へのアクセスを制御するための新しいUIと標準規格がロードマップに計画されています。これは実現する予定ですが、まだ準備できていません。
素晴らしいですね。これらのアクセス制御設定に統合されたUIが導入されるのを楽しみにしています。迅速なご返信ありがとうございます。
完璧です、@Falco さん、ありがとうございます。私のほうからはこれ以上質問はありません