Effective ways to handle more audience in audio only sessions

Greetings everyone!
I’m fairly new to Mediasoup. So please forgive me if I’m asking any silly question.
Our organisation is using MiroTalk SFU which is built on top of Mediasoup. We conduct audio only sessions daily on it. Only 1-2 speakers are allowed to turn on their mic, rest everyone is listener.
As per my knowledge, SFU servers are supposed handle quite good amount of traffic but our server is hardly able to handle 50 participants.
As soon as we start reaching 50, many people start facing audio issues.
We have also noticed that laptop users face relatively fewer issues than mobile users.
My server specifications are:
• 2 core CPU
• 8 GB RAM
• 2 TB bandwidth

I’ve even opened tcp and udp ports from 40000 to 41000.

Mirotalk uses opus as it’s audio codec and is configured at 48Mhz clock rate with 2 channels.
Any suggestions, tutorials or any piece of advice would be very helpful.

That’s weird, you can on a traditional CPU run 200-300+ audio only streams. I am speaking of single core capability as well. I think I averaged out CPU usage to be about 0.2-0.4% per audio stream.

I can’t speak on your code but sounds like some extra work.

Yes I have also read that SFUs are capable of handling quite large amount of traffic on less resources.
@miroslavpejic85 could you please help with this?

Please don’t mention specific people in this forum. This is a community rather than a place to ask for free consultancy services to individuals.

1 Like

I don’t mess with hosts that set a bandwidth limit, or lie about their speeds by hijacking the speedtests. But I would definitely perform some network tests or try other hosts if the CPU isn’t at 100% when you reach 50+ participants on a single core level.

Ohh sorry.

As per what you’re saying here it seems your problem relies mostly client-side.
Are you creating producers/consumers for all the participants despite having only 2 speakers?

If that’s the case, you could create the producers for the “speakers” only, and each of the “listeners” will consume only those 2, with no need to know about the rest of the participants at the WebRTC level.
This will alleviate server-side resource consumption as well of course as you’ll have only 2 producers and (50-1)*2 consumers, instead of 50 producers + (50-1)*50 consumers.