Determine max concurrent users

[capnmidnight]

The limiting factors on the number of users that can be present in the system:

• Jitsi Meets limits
• Avatar/map rendering.
• Spatialization parameter calculation.

Once the nominal max is determined, display it as a subscript on the User List button.

[chrysn]

When Jitsi Meet limits trigger for large environments (which I guess will be the first if all else is done efficiently), it may be possible to compartmentalize Calla rooms into different Jitsi rooms, based on the observation that typically not everyone is within everyone else's earshot.

Even without the software's ability to join more than one Jitsi video room simultaneously, unless people very deliberately try to trick the system, compartimentalization should be possible. (Only when many people spread out in a regular grid, the software would need to tell some users visually that while their "neighbor" is theoretically within earshot, the software muted the other because they were being mean to the software ;-) ).

A rough algorithm for picking rooms that works even without server software (which is a feature of Calla-as-I-understand-it I extremely appreciate!) could be:

• Along with their position, players send an (initially random) sub-room name, and a flag that they feel responsible for that sub-room. While they're out of earshot of anyone else, they may not have joined that room yet even.
• When a player moves and feels responsible for a sub-room, it tries to delegate responsibility for the sub-room to another player (prefering those that haven't moved in some time) by messaging them an offer to take over the room. If nobody takes over the room, it's abandoned.
• When a player has moved (thus has no room responsibilities) and is in earshot of two rooms, and their participant sizes add up to no more than the limit of Jitsi rooms (with some comfortable headspace to avoid flickering), it asks to transition the smaller to the larger. Otherwise, it picks the larger and gets a visual indication that some people within theoretical earshot can't be heard. (I expect this to be rare, as long as Jitsi Meet limits and default earshot match to the point where you'd need to extremely crowd to hit the Meet limits, or construct lattices)
• When a player has moved, joins a room and thus the room becomes too large, the responsible player picks another player and asks them to open up another room and become responsible there.

The limits of earshot should be taken generously for the purpose of joining rooms; otherwise, when you join a chatting group, people get "connecting" screens. These hinder interaction models where you pass by a group and hear a few words of the conversation (helping the decision of whether to join), as you'd need to actively stop and wait for the connection to come up. (I've seen that happen in gather.town, which only takes up connections once you're actually in earshot).

[capnmidnight]

I've given a fair amount of thought to the idea of sub-room clustering and it's not an easy issue.

Rooms are the only unit of communication in Jitsi. The serverless architecture of Calla requires being able to send private messages through the Jitsi room to be able to update users with their individual locations. There is no cross-room communication. So visibility and audibility between users are fundamentally linked.

Now, it might be possible to perform the subgrouping as you've describe, keeping the individual streams between users in subgroups, then having the server combine all audio in a subgroup into a single stream to then forward on to users in other subgroups. Unfortunately, that would take modification of Jitsi, which is not something I'm prepared to do.

I imagine, when a user receives a media stream from the server, whenever the user gets too far away, they could just drop their own local track. I just don't know how they would get the connection back again. Of course, we get the media stream before the position metadata. The DataChannel between users isn't established until after the media streams. That's probably just the order of operations within Jitsi.

Maybe if Jitsi could be used as just a TURN server... first establish the DataChannel, then we could manage the WebRTC offers on our own.

[chrysn]

Good point, I did not think of the position data, and fully agree that Calla work on an unmodified Jitsi server.

Is it within the realm of the reasonable to joint Jitsi twice in two rooms from the same device, possibly even using two 'instances' of the Jitsi library? Then one room might be primarily for global chat and other global messages (without the clients actually sending video or audio; I figure then it's becoming largely a Jabber room), and the other(s) could be clustered.

[capnmidnight]

Interesting. I'm not sure. That might be doable.

[jayaddison]

I'm not certain whether there is a requirements fit and/or net-benefit from integration, so take this with a grain of salt, but it could be worth mentioning that breakout rooms may be landing in Jitsi Meet in the not-too-distant future.

That doesn't magically solve issues like where to set the in-game boundaries around breakout groups, server-level scalability concerns, etc, but the notion of "communication channels within a room" sounds like it could be useful here.

As I understand it, the breakout rooms feature is moderator-managed (in terms of the creation of rooms, and assigning users to rooms), so that management functionality would need to be accessible to Calla as an API; I'm not familiar with any of the frontend integration possibilities.

[jayaddison]

I have a sense I might have jumped in here with unwanted / irrelevant ideas rather than valuable contribution, so, FWIW - I've forked the repo and am going to go away and have a look through the issue backlog, try to get familiar with the code as time allows, and see what'd be (genuinely) useful to provide back in terms of changes.

[capnmidnight]

No, that isn't the case. I just...

I've been unable to put much effort into this project. In my own use of it at work, I was/am focused on using it in VR. The 2D use case atrophied and I wasn't sure how I was going to bring them back in line.

Then in mid August of this year, Google deprecated WebRTC "Plan B" session descriptions for WebRTC for Chrome. Google effectively controls WebRTC, as all other browsers need to be able to communicate with the ones browser engine that is used by 80% of the internet, so that meant their word was final. It had been a year since I last upgraded Jitsi, and even in early August they didn't have "Unified Plan" support ready. So I wholesale replaced my usage of Jitsi and set up CoTURN. I had already been managing my own rooms on a WebSocket server, because I couldn't get the metadata througput necessary for VR strictly through Jitsi's data channel support (for whatever reason, it caused a lot of problems if I sent more than 4 updates a second). So by that point, there wasn't a lot of Jitsi left. Setting up CoTURN was no walk in the park, but once I had it, I realized it was what I should have always done.

So where does that leave Calla? For most of the (admittedly few) people I've ever heard from about it, the thing they cared about the most was the Jitsi support, as it promised a certain simplicity of setup. CoTURN's documentation is impenetrable, and there is no guidance on good defaults. To me, the main value is in the management of the audio graph. So to bring Calla back in line with my latest version of the code would be a huge change of course.

Actually, I need to back pedal a bit. The thing most people seemed to want was for me to stand up a hosted service. That would mean basically starting a new, part-time job of running the hosted service, and the hours would be significant, especially at the beginning. With two kids I don't have time to have two jobs, and I love my current job, I'm not leaving it anytime soon. So if I were to create a hosted service, the best case scenario for the users would also be my worst case: it takes off in popularity and I'm left with a decision on who to disappoint, my employer, my kids, or my users.

So, I don't know what to do. In the year that I was actively pushing Calla, nobody stepped up to be a co-maintainer. It's kind of the same story for all my projects. I make a thing, the FOSS community pushes and pushes to see it open sourced, I do so, and then nobody cares anymore. It's a lot of work to create and support an open source project and it's not showing up in any sense of reward for me.

OSS once represented a dream for me, an escape hatch out of jobs I hated. Well, both the dream is a myth and I don't need the dream anymore. So I'm inclined to quit opening my code and just focus on my job.

[jayaddison]

Thanks for the honest reply!

Despite my best intentions, I haven't gotten around to reading much of the code or backlog here yet..

One way I look at open source is that once the code is out there, it's out there for the long-haul. You never know how long a project might take to really start gaining traction and community -- and it might never do, but as long as it's available to all, it has the chance to.

Half of the bugs I end up fixing on my own projects are basically the result of in-person conversations - show the thing, try a feature, it doesn't work (typical), spend a day or two fixing that, and then nothing will happen on the project for months. I don't have kids, but I do have a full-time job, and I get how "other life stuff" just takes priority, it's natural.

FWIW: I think a talk about your experience here would make for really interesting material at some kind of indie developer conference, should you feel up to it. There's a ton of neat technical concepts to talk about in terms of spatial audio, but then also the challenges of spinning this up, balancing life and technical stuff, and the ways in which open source communities can be lacking. I'm pretty guilty of thinking of ideas for talks and then never doing those, so.. take with a grain of salt, I suppose.

[capnmidnight]

archiving