Roxie Linden

That's certainly an interesting idea. There are all sorts of things that would need to be sorted out, of course. What to do when the mix of attendees changes? Is geolocation sufficient? Would the improved latency be sufficient to make much of a difference for practical purposes. I'll think on it.

Hi all, sorry for the delay in commenting on this (I've been heads-down tying up loose ends on this feature.) (just confirming some of which was said above and hopefully expanding on it.) As far as security goes, we are not using WebRTC to connect client-to-client, even in when calling a single peer. We bounce all connections off of a webrtc server (a WebRTC MCU - see more info on that here.) Because we bounce everything off of our MCUs, IP addresses are not leaked. Additionally, we have more control over authentication, authorization, and encryption. All attempts to to connect to a P2P, conference, Group, or Spatial voice channel are authenticated by the simulators involved. When users are kicked, they cannot reconnect to the same channel as the simulator will deny them, hence the voice server won't allow them to connect. WebRTC itself is encrypted with SRTP/SCTP. As far as audio quality, we're running at a 48khz sample rate overall (mono to the server, stereo from the server), which is an improvement over Vivox for the most part. Running at a higher rate than that is pretty strenuous for the server, which potentially means fewer participants can take part. Bandwidth for those running on lower quality networks is also a concern. Still, there is more we can do, and because we have access to the open source code involved, and we're using our own code, we can make changes based on the needs of the community (unlike the old system.) If you do want to try performing using WebRTC... We've done what we can to address latency, but the simple delay in sending data down to the server and back up does add some. Depending on network conditions, we're talking 100ms-200ms perhaps. That can be a challenge if you want a 'tight' sound, but sing-alongs might be a possibility. Musicians who want to play with one another could use direct p2p links through some other channel as their 'monitor' source, then stream down to SL, which may reduce perceived latency. You'll have to experiment. WebRTC does have pretty decent noise cancellation, echo cancellation, and automatic gain control which should improve things overall for most cases, but for performers, those things are not desired, so I'd like to give some user control over those things. The google WebRTC core code gives pretty fine-grained control over those features. Performers are important, so we'll take their needs into account in the future. By all means, drop us a note at https://feedback.secondlife.com/webrtc-voice so we can track your needs. As far as avatar limits, right now I'm clamping spatial voice at 100 participants, but that may change as we evaluate performance of the servers further (hopefully for the better.) Group/conference sessions are currently capped at 50 participants in WebRTC, but again that may change. We also have some other limitations - you can only hear the 8 or so others who are loudest to you, depending on position and signal strength and such. Hopefully, you won't have 8 people yelling into your ears when you're at a concert. We may tweak that number depending on server performance and community needs. Feel free to ask additional questions.