En réalité, beaucoup d’utilisateurs du forum sur lequel je suis communiquent généralement dans des environnements extérieurs, et rejoindre directement avec le micro ouvert peut provoquer des interférences dues au bruit ambiant. Il y a aussi un autre bug : même si vous cliquez pour couper le micro sur la page vocale, le micro reste en réalité ouvert, et il faut le désactiver puis le réactiver pour le fermer véritablement.
Par rapport à Jitsi, il y a quelques différences, car Jitsi propose une interface qui permet de choisir de couper ou de réactiver son micro avant de rejoindre officiellement la discussion vocale, mais Discourse Voice n’en dispose pas. Je pense que cette interface évite largement ce problème.
Ah, je vois. Ces utilisateurs bénéficieraient-ils de la PTT ? Nous en prenons en charge les bases, mais une meilleure expérience PTT, aussi bien sur mobile que sur bureau, nécessite un peu une application native, et c’est un domaine que nous explorons activement.
Auriez-vous d’autres hypothèses ? J’ai essayé d’inviter un autre utilisateur de démonstration, mais malheureusement, ça ne fonctionne toujours pas. Êtes-vous parvenu à inviter des utilisateurs via un lien ?
Mise à jour : Je viens d’envoyer une invitation à un administrateur pour une nouvelle salle, et il a toujours reçu une page 404.
@putty il est possible que le problème provienne de votre nom d’utilisateur sur le site. La route dans votre enregistrement d’écran se termine par /invited-by/derek.putnam, et cette route rejette actuellement les points dans les noms d’utilisateur. Cela devrait corriger le problème :
Vous pouvez également tester sur votre site en partageant le lien sans la partie /invited-by/....
Nous l’avions utilisé ce week-end avec de bons résultats Un bug / comportement inattendu que nous avons constaté est que le système prend en charge les microstères. Normalement, dans les logiciels de visioconférence, les canaux gauche et droit sont convertis en mono, car le matériel micro en mono est généralement utilisé pour ce type de capture audio. (Cela réduit également théoriquement la consommation de bande passante). La solution Discourse transmet actuellement le micro en stéréo complet.
Cependant, certains microphones ne sortent le signal que sur un canal et laissent l’autre vide. (Peut-être est-ce plus courant pour les interfaces audio pro qui ont plusieurs entrées, mais j’imagine que certains microphones bon marché peuvent aussi se comporter ainsi). Cela a pour effet que les auditeurs n’entendent le locuteur que dans l’oreille gauche ou droite. Je ne m’en étais pas rendu compte, mais apparemment Mumble, Discord, Nextcloud, Jitsi, les jeux, etc., convertissent tous le signal en mono.
Je recommande donc de convertir par défaut le flux audio du microphone (et non le flux audio du partage d’écran, qui devrait être un ensemble de canaux séparé) en mono. En règle générale, il y a probablement peu de situations où l’utilisateur voudrait réellement une large zone de capture audio pendant un appel – peut-être si un groupe de musique l’utilisait pour diffuser en direct à ses fans, par exemple. Dans ce cas, si l’utilisateur possède et souhaite utiliser un microphone stéréo à large angle, il devrait pouvoir l’activer via les paramètres, ce qui désactiverait la conversion en mono.
Si je ne me trompe pas, nous effectuons un downmix pour toutes les qualités audio, sauf pour la qualité maximale. Pourriez-vous essayer de la baisser à « haute » ou « standard » ?
Merci pour ces informations, j’essaierai la prochaine fois, mais il serait plus idéal de pouvoir activer ou désactiver cette option indépendamment, sans avoir à réduire le débit.
Nous utilisons les salles vocales depuis quelques semaines, avec des groupes limités (5 personnes maximum). Jusqu’à présent, tout fonctionne bien — félicitations ! J’aimerais que le backend technique soit séparé de l’application web et de la base de données Discourse. Existe-t-il une bonne documentation sur la manière de configurer un serveur LiveKit avec Docker Compose (avant de demander à Claude ) ?
Avec la configuration par défaut, comme avec la configuration Livekit, Discourse reste chargé de la même quantité de responsabilités. Mesh est un bon choix par défaut, et s’il vous convient, je vous recommande de vous y tenir tant que vous n’avez pas dépassé ses limites.
Merci @Falco – c’est encore mieux si nous n’avons rien à modifier. Je vais donc ouvrir cette fonctionnalité à toutes les communautés sur notre instance, mais en la limitant à 5 personnes par salle. Pour la plupart des réunions improvisées, cela suffit largement.
Une note sur la confidentialité : à l’avenir (peut-être à un stade ultérieur du projet « Salle vocale »), nous aurons besoin d’une solution documentée pour garantir une pleine conformité au RGPD : actuellement, stun.l.google.com et global.stun.twilio.com sont les valeurs par défaut. Les deux sont basés aux États-Unis et doivent donc se conformer au US Cloud Act, ce qui entre en conflit avec la juridiction européenne.
Veuillez m’excuser si cette question a déjà été traitée :
L’annonce de l’auteur du sujet (OP) énumère les « salles publiques, restreintes à un groupe et privées » sous les permissions des salles, mais je ne parviens pas à trouver où configurer la restriction par groupe pour une salle.
Mon cas d’usage : une salle visible et accessible uniquement aux membres d’un groupe spécifique, en gros comme une Catégorie. Les paramètres voice_allowed_groups et voice_create_room_allowed_groups sont appliqués à l’échelle du site, ils ne couvrent donc pas ce dont j’ai besoin ici.
Dans l’éditeur de salle, je ne vois que le basculement Public et la gestion des membres par utilisateur.
La restriction par groupe au niveau de chaque salle est-elle implémentée ? Si oui, où se trouve le paramètre ? Sinon, est-ce prévu ? Je suis prêt à le tester.
Pour beaucoup de mes communautés, les Catégories, le Chat et le Voice seraient des ressources qu’un Groupe souhaiterait utiliser de manière exclusive ; la possibilité de contrôler leur accès par groupe figure donc très haut sur ma liste de priorités.
Pas encore, actuellement tout est basé sur les utilisateurs.
Comme vous l’avez mentionné, @mcwumbly a un plan dans la feuille de route pour une nouvelle interface utilisateur et un standard pour contrôler l’accès à des fonctionnalités comme les salons de discussion et les salons vocaux. Cela va se faire, mais ce n’est pas encore prêt.
Ça a l’air génial. J’attends avec impatience une interface utilisateur unifiée pour ces paramètres de contrôle d’accès. Merci pour ta réponse si rapide.
Un bug / comportement inattendu que nous avons constaté est que le système prend en charge les microstères. Normalement, dans les logiciels de visioconférence, les canaux gauche et droit sont convertis en mono, car le matériel micro en mono est généralement utilisé pour ce type de capture audio. (Cela réduit également théoriquement la consommation de bande passante). La solution Discourse transmet actuellement le micro en stéréo complet.
) ?