Comment créer un salon de discussion vocale (voice room) : Micros / Mixage / Réseaux faibles / Liste de contrôle pour la mise en œuvre du programme Gift Bounty

Les salons de discussion vocale (également connus sous le nom de “voice rooms”, "voice parties" et "voice spaces") peuvent ressembler à des "salles de discussion", mais lorsqu'ils sont réellement en ligne, ce sont toujours les quatre endroits où il est le plus facile d'échanger :Gestion de la position du blé(Commande),Expérience audio(écho/bruit/volume),Faible réseau disponible(Bégaiement/déconnexion/reconnexion),faire preuve d'appréciation(Contrôle du jeu et du vent).

Cet article ne parle pas de concepts, il vous donne directement un ensemble de 0 à 1 qui peut être ancré dans la “liste de mise en œuvre”, divisée par module, que vous suivez pour faire fonctionner en ligne une salle vocale.

1) Tout d'abord, faisons le tri dans la “voice room” : quelle est votre fonction ?

Les différents types déterminent la voie technologique, le coût et la complexité que vous choisissez.

1.1 Petites salles avec une forte interaction (typiques : salles d'expression sociale)

• Taille de la salle : des dizaines ou des centaines de spectateurs en ligne
• Nombre de personnes au micro : généralement de 1 à 12 (souvent 8/9 micros)
• Caractéristiques : forte interaction, faible latence, ordre de blé important

1.2 Grande salle de diffusion biaisée (typique : le présentateur parle, le public écoute)

• Nombre de pièces : de milliers à 100 000
• Nombre de personnes au micro : peu (1-3)
• Caractéristiques : plus proche d'une diffusion en direct, de nombreuses équipes utiliseront le RTC pour réaliser un microphone continu, et le CDN pour réaliser une distribution à grande échelle (en fonction de la forme de votre produit).

Cet article est rédigé par défaut Une forte interaction dans une petite salleParce que c'est l'ensemble de capacités “mike/mix/weaknet/gift” le plus courant et le plus nécessaire.

2. architecture globale : système minimum viable (MVP) pour les salles vocales

Vous avez besoin d'au moins 4 liens :

1. Systèmes de chambres et d'utilisateurs (back-end)

• Création de salles, entrée et sortie, propriétés des salles (titre, annonce, mot de passe, balises)
• Liste des membres, statut en ligne, rôles (propriétaire/administrateur/public/invité)

2. Système de signalisation (synchronisation des ordres et des états)

• Demander un micro, retenir un micro, exclure un micro, interdire un micro, fermer un micro
• MIC STATUS BROADCAST (qui est sur quel micro, en sourdine ou non, icône de qualité du réseau)
• Messages cadeaux, annonces du système, événements de la salle

3. Audio en temps réel (lien média RTC)

• Entrer dans la salle, publier de l'audio, s'abonner à l'audio
• Traitement audio (AEC/réduction du bruit/gain automatique)
• Faible politique de réseau (perte de paquets, gigue, reconnexion)

4. Système de cadeaux/récompenses (paiement + contrôle des risques)

• Passation de commande, rappel de paiement, arrivée, inventaire/sac à dos (optionnel)
• Messages d'affichage de cadeaux, listings, effets spéciaux (la lumière peut être faite en premier)

En résumé :
La RTC est responsable de “parler clairement, ne pas rompre la ligne, faible latence” ; la signalisation est responsable de “l'ordre” ; et les cadeaux sont responsables de la “réalisation”.

3. le système de blé : le “centre de commande” de la chambre vocale”

Lorsque la position du micro n'est pas correcte, la salle devient le théâtre d'appels téléphoniques intempestifs, de diaphonies et d'effondrements de la part de la direction.

Quels sont les états nécessaires pour le bit de blé (je vous suggère de copier ces informations dans une structure de données) ?

Chaque bit de blé (siège) contient au moins :

• seatIndex: Numéro de blé (0-7 ou 1-8)
• userIdOccupant actuel (vide = personne)
• lockLe micro peut être verrouillé ou non (personne d'autre ne peut accéder au micro si vous le verrouillez).
• muteBySelf: Auto-extinction de l'utilisateur
• muteByAdminAdministrateur de la sourdine forcée : Administrateur de la sourdine forcée
• audioLevelValeur de volume (pour l'animation de l'interface utilisateur)
• networkQualityQualité du réseau (rouge, jaune et vert)
• roleétiquette propriétaire/guest/administrateur (peut être placée sur l'utilisateur)

Liste des opérations sur les mèches de blé (fonctions communes du produit)

• Posez votre candidature pour le micro: Audience → File d'attente de requêtes (avec délai d'attente)
• Accord/RefusPropriétaire/administrateur → Notification par signalisation + mise à jour de la position du micro
• être libre de prendre l'airLes candidats ne sont pas invités à se présenter, mais à repérer le siège du micro (qui convient à la salle de rencontre).
• cale le maquereauL'administrateur affecte une personne à un certain micro.
• lancer un microL'administrateur retire quelqu'un du micro
• Verrouillage/déverrouillage du microLes prises de son : Éviter les prises de son désordonnées
• Micro fermé/ouvertLes administrateurs contrôlent si une cabine particulière peut parler ou non.
• Changement d'espace pour le blé/Swapping Wheat Spaces: deux positions de micro échangées (pour améliorer l'expérience)
• délai d'attente sur le microLa demande sera annulée automatiquement si vous ne prenez pas le micro : X secondes après l'approbation de la demande.
• siège déconnectéLe micro est gardé pendant N secondes après l'abandon de la ligne (clé de l'expérience).

Fortement recommandé : “Rear-end is the authority” pour l'état du micro.”

Beaucoup d'équipes commencent avec une synchronisation côté client uniquement et se retrouvent avec un état erroné sur des connexions faibles/multiples/reconnexions.

Vous pouvez le faire :

• Le backend enregistre l'état du micro de salle(Le stockage léger Redis est suffisant)
• Tous les changements de bits passent par un “événement de signalisation”.
• Le client ne fait que rendre l'état et ne s'arbitre pas lui-même

De cette manière, lors de la reconnexion, le client tire une fois l'instantané de la pièce et récupère.

4. le mixage audio et la qualité du son : les utilisateurs restent quand ils l'entendent bien

Expérience audio dans la salle vocale = “entendre clairement + pas de dureté + pas de souffle du microphone + pas d'échos”.

4.1 Quad de traitement audio (en principe tous activés)

• Annulation de l'écho AECÉviter le sifflement dû à la lecture externe : Éviter le sifflement dû à la lecture externe : Éviter le sifflement dû à la lecture externe
• NS Annulation du bruitBruit ambiant (ventilateur, clavier, bruit du véhicule)
• AGC Auto GainLe volume faible tire vers le haut, évitant ainsi le volume sonore.
• VAD Détection vocale (en option): une pression de fond plus intelligente

Si vous utilisez un SDK RTC mature, ces derniers ont généralement des politiques par défaut ; tout ce que vous avez à faire, c'est.. :

• Fournir aux utilisateurs des “Interrupteur de réduction du bruit”
• Fournir aux propriétaires “Mise en sourdine/hors sourdine complète”
• Oui.“blé frit”Protéger (dire ci-dessous)

4.2 Protection contre les explosions et les ruptures (obligatoire)

Les scénarios de micro soufflé sont fréquents : les utilisateurs s'approchent trop près, le microphone du téléphone est surchargé, la musique est mise trop fort.

Des moyens réalisables :

• Limite du volume d'entrée (gain d'entrée)
• Activation de la CAG/du limiteur (limitation des crêtes)
• Rappel de l'interface utilisateur : “Éloignez-vous du microphone/réduisez le volume du système”.”
• Détection des pics soutenus dépassant le seuil → réduction automatique du gain

4.3 Musique de fond (BGM) et effets sonores (facultatif, mais un plus)

Façons courantes d'utiliser la salle vocale : chansons, effets sonores, changements de voix, tonalités.

Il existe deux types de réalisation :

• Mélange local côté clientLes services d'aide à la décision : Faible latence et mise en œuvre rapide (mais il faut veiller à la cohérence à toutes les extrémités).
• Mélange côté serveurCohérence forte (coût et complexité plus élevés)

MVP recommande de commencer par le mix client, c'est garanti :

• Le volume du BGM et les voix sont automatiquement atténués (la musique diminue lorsque les gens parlent).
• Quitter la pièce pour arrêter la lecture et éviter la consommation d'énergie en arrière-plan

5. réseaux faibles et reconnexions : la clé pour “survivre” à la chambre vocale

La faiblesse de l'internet n'est pas une situation minoritaire, c'est la norme : métros, ascenseurs, gigue de la 4G, commutation du Wi-Fi.

5.1 Liste des stratégies de réseaux faibles que vous devez avoir

• Rapports sur la qualité du réseauL'interface utilisateur affiche le rouge, le jaune et le vert (le propriétaire peut voir qui est bloqué).
• Contre-mesures en cas de perte de paquetsLa continuité de la voix : Priorité à la continuité de la voix, permettant une réduction appropriée du taux de codage
• Stratégie de tampon de gigueÉviter l'intermittence
• Traitement de la commutation Wi-Fi/cellulaireLes décalages de courte durée lors de la commutation devraient se résorber d'eux-mêmes.
• se reconnecterConnexion automatique + indication de l'état de l'interface utilisateur lors de la reconnexion
• siège déconnectéLe micro est un outil d'aide à la décision : il se déconnecte et revient dans les N secondes qui suivent et occupe toujours le micro (expérience forte).

5.2 Recommandations pour le processus de reconnexion (l'ensemble le plus sûr)

1. Déconnexion des médias détectée (ou détérioration du réseau jusqu'au seuil)
2. L'interface utilisateur affiche “Reconnexion...”.”
3. Reconnectez-vous d'abord à la salle RTC (join).
4. Chargement d'instantanés de la salle (mike/personnage/statut banni)
5. Si l'utilisateur était dans le micro et que sa réservation de place n'a pas expiré, → reprend automatiquement le micro.
6. Rafraîchir la liste des membres avec l'animation du volume après achèvement

Points clés :reconnexion des médiasetRécupération de la conditionIl faut le faire ensemble, sinon “le son revient, mais le micro est toujours vide/occupé par quelqu'un d'autre”.

6. récompenses pour les cadeaux : jeu minimum disponible + liste de contrôle des fenêtres

Les écueils les plus fréquents du système de cadeaux de la Voice Room sont la “cohérence des paiements” et les “litiges liés à l'utilisation des cadeaux, à la sous-utilisation et au remboursement”.

6.1 Système de cadeaux MVP Tout ce dont vous avez besoin, c'est de cela !

• Liste de cadeaux (ID, nom, prix, icône)
• Passer une commande (générer un numéro de commande)
• Callbacks de paiement (callbacks de tiers vers votre backend)
• Résultats de l'émission (succès/échec)
• Diffusion d'un “message cadeau” dans la salle (pour l'animation de l'interface utilisateur)
• Liste simple (contribution d'aujourd'hui / contribution de ce jeu)

Principes clés du MVP :
Le succès du paiement est soumis au “backend callback”.Ne faites pas confiance au client.

6.2 Contrôle des vents et conformité (faire au moins ceci)

• limitation de la fréquenceLimitation du nombre de cadeaux sur une courte période pour un même compte/appareil
• détection des anomaliesLes anomalies sont les suivantes : petites quantités à haute fréquence, seconds passages, anomalies d'une pièce à l'autre.
• Stratégie de traitement des remboursementsListe des cadeaux : Les cadeaux sont-ils révocables ? Comment la liste est-elle annulée ?
• Protection des mineursNoms réels/limites/alertes contextuelles (selon les règles de votre plateforme et de votre région)
• gouvernance des contenusLe processus de signalement, de bannissement et de blocage (même s'il s'agit d'abord d'un backend manuel) pour la pornographie, la politique, les abus, etc.

7) Gestion de la chambre : si vous ne le faites pas, votre chambre sera sûrement nulle !

La Voice Room n'est pas un produit technique, c'est une “semi-communauté”.

Donner au propriétaire/administrateur au moins ces capacités :

• Bâillonnement (individuel ou total)
• Expulsé de la salle (durée facultative de l'interdiction)
• Liste noire/liste blanche (très utile pour les salles familières)
• Blocage des mots-clés (pour les messages textuels/les noms de salle)
• Portail de reporting + traitement du back-office (journalisation minimale)

8. comment choisir le mode d'atterrissage)

Il y a deux façons d'obtenir une chambre vocale :

Itinéraire A : Construction autonome (WebRTC + SFU/serveur multimédia)

Avantages : contrôlable, personnalisable, potentiellement plus économique à long terme
Inconvénients : lourdeur du système Dev/Ops, nombreux problèmes de compatibilité et de faiblesse du réseau, lenteur de la mise en service.

Itinéraire B : Utiliser le SDK RTC mature (atterrissage le plus rapide)

Avantages : démarrage rapide, traitement réseau/audio faible et mature, support cross-side pour une plus grande tranquillité d'esprit
Inconvénients : nécessité de payer au volume, certaines capacités de profondeur limitées par le fournisseur.

Si vous souhaitez mettre en place votre salle vocale et la faire fonctionner le plus rapidement possible (position du micro, réduction du bruit, écho, faibles reconnexions au réseau, tous ces éléments sont facilement disponibles), vous pouvez accéder directement à un SDK audio/vidéo en temps réel éprouvé. J'ai mis en place un portail de démarrage rapide (avec console et démo) ici :La solution de salle de discussion vocale de Tencent RTC

Liens connexes