Our great sponsors
-
Hi everyone,
a few days ago @DoubleMalt, @mitschabaude and me did a one-day hackathon to see if we can get a minimal WebRTC based version of a Clubhouse-style "room" to work.
Since then we added a TURN server, bug fixes ("can you hear me?") and a bit of ui polishing.
Jam should run in any modern browser but the long-tail of browsers and operating systems is … long, so please let us know if it does not work for you, and what you are using. We want Jam to run if it can run. If your toaster supports WebRTC it might run Jam as well.
We tried to keep the implementation fairly minimal, I'm sure there is more we can remove and simplify once we spend more time on it.
https://gitlab.com/jam-systems/jam
Please give it a try and let us know what you think. Any thoughts, comments, feature requests, hosting-deploy-target requests etc etc highly appreciated.
(for those who are not familiar with Clubhouse yet:)
A room in Clubhouse (or on Twitter Spaces) is a bit like Zoom without video, without screen sharing and without text messaging.
You see a grid of all the people in the room, who is speaking, who would like to say something (slow mute/unmute flashing), who is clapping (fast mute/unmute flashing) and that's it.
Over the past few years I experienced what we all now call "Zoom fatigue". I just don't enjoy video calls. When the pandemic started it felt like even people who in the past were happy with phone calls also wanted to jump on Zoom calls. I'm glad that eventually slowed down again.
I'm super excited about Clubhouse, Twitter Spaces and the activity around audio spaces and live calls.
In hindsight it is fascinating how the ui for group phone calls on smartphones has not advanced much compared to the non-smart phones.
-
Amazing work! The WebRTC community needs something like this so bad. Not only will this push a bunch of users toward self-hosted/free software but will also inspire others to build cool things :)
If/when you hit scaling challenges I would love to help! I maintain github.com/pion/turn and github.com/pion/webrtc. You can see that with how screego[0] does it.
Happy to help however I can (even if not using Pion!) One of the reasons I built it was so that I could put my TURN and Signaling server in the same process. It makes it way easier to tie your auth together for signaling+TURN. Then if you do go down the SFU route lots of interesting things you could do.
[0] https://github.com/screego/server/blob/e845b3d29c4b5794ed10f...
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
WebRTC-Scalable-Broadcast
Discontinued This module simply initializes socket.io and configures it in a way that single broadcast can be relayed over unlimited users without any bandwidth/CPU usage issues. Everything happens peer-to-peer!
Perhaps Scalable WebRTC could help you there? Pure client mesh https://github.com/muaz-khan/WebRTC-Scalable-Broadcast without having to add more servers on your end to mix anything
-
Nice project. For server side mixing, how hard would be to integrate Jam with Mumble? There is a Github repository that does it: https://github.com/Johni0702/mumble-web
-
Nice work! A colleague of mine did a similar thing in 2014 but it bitrotted terribly. Code is at https://github.com/tOkeshu/bananaphone.
-
Not an expert here but have some experience with it:
Assuming that each peer is connected to every other peer via a mesh network [see this image for reference: https://github.com/feross/simple-peer/blob/master/img/full-m...], each outgoing stream (esp. audio / video) is likely going to be duplicated, per recipient.
Scalability over a mesh network is fully dependent on CPU and network performance of all of the connected devices, and I'd doubt it could handle 12 participants if there is video involved, unless all participants are running relatively high-end and modern devices, with optimal network conditions.
You'll need a SFU or an MFU running on the server to handle larger rooms, while enabling all connected devices to only have to send one output stream per media type, regardless of how many connected participants there are.
