Well, actually, many users on the forum Iām on usually converse in external environments, and joining with the microphone open directly can cause ambient noise to interfere with communication. And thereās another bug: even though you click to mute the microphone on the voice page, the microphone is still actually open, and you have to toggle it off and on again to truly close it.
Compared to Jitsi, there are some differences because Jitsi has an interface that lets you choose to mute or unmute your microphone before officially joining the voice chat, but Discourse Voice doesnāt have this. I think this interface largely avoids the issue.
Oh I see. Would those users benefit from PTT? We have basic support for it, but a better PTT experience, on both mobile and desktop, kinda needs a native app, and this is an area we are actively exploring.
Did you happen to have any other guesses? I tried inviting my other demo user and unfortunately itās still not working. Have you been able to successfully invite users via a link?
Update: I just sent an invitation to a new room to an admin, and they still got a 404 page.
@putty itās possible this is an issue with your username on the site. The route in your screen recording ends with /invited-by/derek.putnam, and the route for this currently rejects periods in usernames. This should fix it:
You can also test on your site by sharing the linking without the /invited-by/... bit.
We were using this over the weekend to good effect One bug / unexpected feature we found is that the system supports stereo mics. Normally, on web conferencing software, the left channel and right channel are downmixed to mono since mono mic hardware are typically used for capturing this sort of audio. (This also theoretically reduces bandwidth usage). The Discourse solution currently transmits full stereo mics.
However, some mics will only output to one channel and leave the other empty. (Maybe this is just more typical for prosumer audio interfaces that have multiple inputs, but I imagine some cheap mics might end up doing this, too). This results in the listeners only hearing that speaker in the left or right ear. I actually did not realize this, but apparently Mumble, discord, nextcloud, jitsi, games, etc all downmix to mono.
So, I would recommend defaulting to downmix the mic audio stream (not the screenshare audio stream which should be a separate set of channels) to mono. Generally speaking, thereās probably few situations the user would actually want a wide field of view to capture audio during a call ā maybe if a music band was using it to stream to their fans, perhaps. In that case, if the user specifically has and wants to use a wide-field stereo mic, let them enable it via settings which would turn off the mono downmixing.
We are using the voice rooms for a couple of weeks now, with limited group sizes(max. 5 people). Up to now, all works fine - congratulations! I would like to have the technical backend separated from the Discourse web app and database. Is there some good documentation on how to set up a livekit server with Docker compose (Before I ask claude )?
On the default setup, and on the livekit setup, Discourse still handles the same amount of responsibility. Mesh is a good default, and if it works for you Iād recommend keeping with it until you outgrew it.
Thanks @Falco - even better if we donāt need to change anything. Then I will open the functionality for all communities on out instance, but ways limited to 5 persons per room. For most ad-hoc meetings, this is fairly enough.
A note about privacy: In the future (maybe at a later stage of the āVoice roomā project), we would need a documented solution for full GDPR-compatibility: Currently stun.l.google.com and global.stun.twilio.com are default. Both are US-based and thus have to follow the US cloud act, which conflicts with the european jurisdiction.
The OP announcement lists āpublic, group-restricted, and private roomsā under room permissions, but I canāt find where to set group restriction on a room.
My use case: a Room visible and joinable only by members of one specific group, basically like a Category. The voice_allowed_groups and voice_create_room_allowed_groups settings are site-wide, so they donāt cover what I need here.
In the room editor I only see the Public toggle and per-user Manage members.
Is per-room group restriction implemented? If so, where is the setting? If not, is it planned? Happy to test it.
For many of my communities Category, Chat and Voice would be resources that one Group would like to have for their exclusive use, so being able to access-control them by Group is high on my list.
As you mentioned, @mcwumbly has a plan on the roadmap for a new UI and standard to control access for features like chat rooms and voice rooms. This is going to happen, but it is not ready yet.
One bug / unexpected feature we found is that the system supports stereo mics. Normally, on web conferencing software, the left channel and right channel are downmixed to mono since mono mic hardware are typically used for capturing this sort of audio. (This also theoretically reduces bandwidth usage). The Discourse solution currently transmits full stereo mics.
)?