Is there data support 500+(audio) in one conference?
In our project, 106 is up limit, the server hardware is as follows:
How to increase it? Is PipTransport the solution?
Did you already read mediasoup :: Scalability?
No one has a magic ball to give predictions on how your application will scale with mediasoup. But you can read above documentation and search the forum for hands on experience of other people so far.
1 Like
You’d require 21 - 60+ CPU cores to handle 500 viewers, but this doesn’t mean 500 audio broadcasts. You’d need significantly more servers to be able to run that.
Overall bad idea, unless it’s a few broadcasters to many viewers situation.
So yes you can however it’s no ideal.
Yes, We are now trying to figure out how to use several servers with the different hosts to work for one 500+ viewers conference.
May be mediasoup :: Scalability is the solution.
[shameless plug]
I’m working on Mafalda SFU, a solution for vertical and horizontal scaling build on top of Mediasoup. Horizontal scaling is not fully finished, but vertical scaling can help you on this topic with a powerful server.
1 Like
Yes, you’d need to route a pipe and go from there, but the major concern is the client performance in these scenarios and all sorts.
You can look at my scalability post to seek out a route for yourself. I do recommend it for gaining an idea!
1 Like
Yes, It is possible to have a 500+ user audio conference. The way to achieve it is by using the pipeToRouter function as provided by mediasoup. This is how one can calculate the needed resources for a 500 user audio conference.
Each user will receive 499 streams from all other users excluding self.
So total 500 X 499 = 249500 streams. (N X N-1)
Considering each mediasoup router can handle 500(approx) consumers / audio streams, one needs 499 CPU cores to cater the demand. This may technically be possible on the server side but may not feasible in the client side due to limitations of a client side network condition and CPU capabilities to decode that many bytes of data in real time.
The ideal thing will be to keep 50 users in a conferencing mode and rest all in a listen only mode along with a feature to bring a listen only viewer to a conversation like clubhouse does.
Why 50 in conference because both network and CPU of the client device will able to handle it without much effort.
Considering each audio stream takes 42 kb/s with OPUS as codec meaning 50 X 42 kbps = 2 Mb/s should be okay from both network and CPU capabilities of the client device.
50 user conference and 450 in listen only mode is going to change the numbers dramatically.
50 user in conferencing mode : 50 X 49 = 2450 consumers / 500 consumer per core = 5 cores needed in the conferencing mode
450 users in listen only mode consuming 50 streams from all participants which is 450 X 50 = 22500 consumers / 500 per core = 45 cores
Total 50 cores need to cater 500 participants.
If you are taking a single machine with 50 cores then only pipeToRouter() is enough ELSE you need to implement the inner functionality of pipeToRouter() i.e. the way it creates pipeTransports and connects it, on different routers available on 2 different hosts/ VPCs.
Hope it helps.
2 Likes
In most conversations, only one person is talking at a time… when you have more than 3 people talk at the same time, it is chaos. The key is to limit the number of audio stream you forward to all the participants.
Maybe you can have mic control where people open their mic when they want to speak and everyone else is listening… otherwise, you can do voice detection and only forward audio when someone is speaking.