In realtà, molti utenti del forum a cui partecipo conversano tipicamente in ambienti esterni, e unirsi con il microfono già attivo può far sì che il rumore di fondo interferisca con la comunicazione. C’è anche un altro bug: anche se si clicca per disattivare il microfono nella pagina vocale, il microfono resta in realtà attivo, e bisogna disattivarlo e riattivarlo per chiuderlo davvero.
Rispetto a Jitsi, ci sono alcune differenze, perché Jitsi offre un’interfaccia che permette di scegliere se attivare o disattivare il microfono prima di unirsi ufficialmente alla chat vocale, ma Discourse Voice non ha questa funzione. Credo che un’interfaccia del genere eviti in gran parte il problema.
Ah, capisco. Quei utenti trarrebbero vantaggio dalla funzione PTT? Abbiamo un supporto di base, ma per un’esperienza PTT migliore, sia su mobile che su desktop, serve un’app nativa, ed è un’area su cui stiamo lavorando attivamente.
Avete per caso altre ipotesi? Ho provato a invitare un altro utente demo, ma purtroppo non funziona ancora. Siete riusciti a invitare utenti tramite un link?
Aggiornamento: ho appena inviato un invito a un amministratore per una nuova stanza, ma ha comunque ricevuto una pagina 404.
@putty è possibile che si tratti di un problema con il tuo nome utente sul sito. Il percorso nella tua registrazione dello schermo termina con /invited-by/derek.putnam, e attualmente questo percorso rifiuta i punti nei nomi utente. Questo dovrebbe risolvere il problema:
Puoi anche testare sul tuo sito condividendo il collegamento senza la parte /invited-by/....
Nei abbiamo usato questa funzione nel fine settimana con buoni risultati Un bug / comportamento inatteso che abbiamo riscontrato è che il sistema supporta i microfoni stereo. Normalmente, nei software di videoconferenza, i canali sinistro e destro vengono convertiti in mono, poiché per la cattura di questo tipo di audio si utilizzano tipicamente hardware mono. (Questo riduce teoricamente anche l’utilizzo della banda). La soluzione di Discourse attualmente trasmette i microfoni in stereo completo.
Tuttavia, alcuni microfoni outputtano solo su un canale, lasciando l’altro vuoto. (Forse è più tipico per le interfacce audio prosumer con più ingressi, ma immagino che anche alcuni microfoni economici possano comportarsi così). Di conseguenza, gli ascoltatori sentono il parlante solo nell’orecchio sinistro o destro. In realtà non me ne ero accorto, ma a quanto pare Mumble, Discord, Nextcloud, Jitsi, i giochi, ecc. convertono tutti in mono.
Quindi, consiglio di impostare di default la conversione del flusso audio del microfono (non del flusso audio dello screen sharing, che dovrebbe essere un set di canali separato) in mono. In generale, ci sono probabilmente poche situazioni in cui l’utente vorrebbe davvero un campo di ripresa ampio per catturare l’audio durante una chiamata — forse se una band musicale lo usasse per trasmettere in streaming ai propri fan. In quel caso, se l’utente possiede e desidera utilizzare un microfono stereo a campo ampio, lasciamogli l’opzione di attivarlo tramite le impostazioni, disattivando così la conversione in mono.
Grazie per le informazioni, la proverò la prossima volta, ma sarebbe più ideale se potessimo attivare/disattivare questa opzione separatamente, senza dover ridurre il bitrate.
Stiamo utilizzando le stanze vocali da un paio di settimane, con dimensioni di gruppo limitate (max. 5 persone). Finora tutto funziona senza problemi: congratulazioni! Vorrei separare il backend tecnico dall’app web e dal database di Discourse. Esiste una buona documentazione su come configurare un server LiveKit con Docker Compose (prima di chiedere a Claude )?
Nella configurazione predefinita e in quella di livekit, Discourse gestisce comunque la stessa quantità di responsabilità. Mesh è una buona opzione predefinita, e se funziona per te ti consiglio di mantenerla finché non ne avrai più bisogno.
Grazie @Falco - sarebbe ancora meglio se non dovessimo cambiare nulla. In tal caso, attiverò la funzionalità per tutte le community sulla nostra istanza, ma la limiterò a 5 persone per stanza. Per la maggior parte delle riunioni ad hoc, è più che sufficiente.
Una nota sulla privacy: in futuro (forse in una fase successiva del progetto “Voice room”), sarà necessaria una soluzione documentata per la piena conformità al GDPR: attualmente stun.l.google.com e global.stun.twilio.com sono i server predefiniti. Entrambi sono basati negli Stati Uniti e devono quindi rispettare il US Cloud Act, che è in conflitto con la giurisdizione europea.
L’annuncio dell’autore del post elenca le “stanze pubbliche, con restrizioni di gruppo e private” tra i permessi delle stanze, ma non riesco a trovare dove impostare la restrizione di gruppo su una stanza.
Il mio caso d’uso: una Stanza visibile e accessibile solo ai membri di un gruppo specifico, in pratica come una Categoria. Le impostazioni voice_allowed_groups e voice_create_room_allowed_groups sono a livello di sito, quindi non coprono ciò di cui ho bisogno qui.
Nell’editor della stanza vedo solo l’interruttore Pubblica e la gestione dei membri per singolo utente.
La restrizione di gruppo per singola stanza è implementata? In tal caso, dov’è l’impostazione? Se no, è prevista? Sono felice di testarla.
Per molte delle mie community, Categoria, Chat e Voice sarebbero risorse che un Gruppo vorrebbe avere in uso esclusivo, quindi poterle controllare tramite il Gruppo è in cima alla mia lista.
Non ancora, al momento tutto è basato sugli utenti.
Come hai menzionato, @mcwumbly ha un piano nella roadmap per una nuova interfaccia e uno standard per controllare l’accesso a funzionalità come le chat room e le voice room. Questo avverrà, ma non è ancora pronto.
Sembra fantastico. Non vedo l’ora di avere un’interfaccia utente unificata per queste impostazioni di controllo degli accessi. Grazie per la risposta così rapida.