Android performance tuning for 15-20 simultaneous peer connections

[Yuri Tikhomirov]

Hello,

I'm now trying to achieve a real big p2p rooms using WebRTC compiled for Android with non-standard ADM (Audio Device Module).

For now with standard settings (not modifying sdp) I've got a limit of about 6-7 peer connection on my Samsung SM T-705 tablet before CPU overrun. (Not a high-end device for now, but good enough, maybe like Samsung S5 or Note4 smartphones).

I believe I can get 2 or even 3 more if I use standard ADM, but I can't use it since I need some spatialization there...

So the question is: how efficiently reduce the amount of CPU usage? 

I want it to work 2 or 3 times faster to support about 15-20 peer connections with no CPU overrun and better not using more threads than webrtc worker thread and the one where my ADM works and commits audio data to webrtc.

For one peer now it is spent about 210ms per second to: 

1. DeliverRecordedData (most consuming, about 130ms), 

2. RequestPlayoutData (about 60ms, growing with number of peers even when all peer's remote audio tracks are disabled, means set_enabled(false)),

3. Apply spatialization (takes about 15ms, really small complexity),

4. Do minor things like obtaining data from audiosink (about 2ms).

My assumptions on what to do to make it faster were:

1. Somehow tweak opus encoder:

 - forcing maxsamplerate to 24000 is not giving anything according to my benches;

 - settings kDefaultComplexity=1 for opus gives about 15-20ms win, means 10% which is not significant;

 - changing minptime and setting ptime to 40 gives nothing;

 - still I didn't try to play with bitrate, will see tomorrow;

2. Disable DTLS:

 - gives nothing except I can't send binary data via datachannel =\

3. Use ISAC 16khz:

 - it really works lowering from 210ms to 130ms overall to complete (60ms for DeliverRecordedData, 50ms to RequestPlayoutData + ~15ms for spatialization and things)

 - but it sounds not as good as opus =\

So can someone please suggest any other options that will probably give better performance while still using an existing 'assembly'? (I mean, when only ADM is injected from outside, but all other parts of WebRTC kept untouched in it's place and works like in Chrome or wherever else.)

I know I better re-assemble WebRTC for my purposes - to not encode local audio stream for every peer separately, mean, to encode once and for all* (or twice, for two different bandwidths)... but for now 'ain't nobody got time for that' =)

* - am I actually right it encodes N times for N peers or it's just overheads of the data delivery system?

Regards, Yuri.

[Christoffer Jansson]

Hi,

Have you considered using an SFU or MCU instead in order to reduce the load on the clients? Even if you get this working somewhat, the battery will not last for long. IMHO it's better for the user if the server can take most of the load.

Having said (written) that tuning performance is not a bad thing, just not sure how feasible it is to improve it by 2-3 times. 

/Chris

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2b9c5c36-ecdb-4a53-a65b-cbbfde802856%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Yuri Tikhomirov]

Hey Chris, thanks for your reply!

We do not considering it for now. We have a realtime application that requires fast enough response in terms of spatialization. This is VR app, so it's very important to get user immersed, this means, we can't let audio sources be rotated too late after the user turns his head. I mean, using any remote systems to gather audio from peers and spatialize for each individually will most likely bring significant latency and will require a huge distribution of servers over the planet Earth, I guess... since we're like a startup, we can't afford to do that.

And yeah, me also thinks it's almost impossible to improve it 2-3 times from outside, means, not modifying webrtc code or something... But still I'd like to try to get some more peers working stable in this conditions...

среда, 13 июля 2016 г., 9:28:22 UTC+3 пользователь Christoffer Jansson написал:

[Christoffer Jansson]

I see. There is work ongoing to make WebRTC slimmer and perform better but it's still very much work in progress.

/Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c10b9fa6-6db8-4361-b67f-e61a05399608%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

/Chris