Open JimG777 opened 1 month ago
@JimG777 - Yes, this is a problem. High latency makes conversation more awkward. The users will not report "high latency". They just think the other person is being rude and talking over them. So lowering latency for VoIP is a high priority.
With OboeTester, I can see that the latency increases from 20 to 170 msec when I use VoiceCommunication mode and enable an Effects Session for Input. I was able to get a LowLatency output path on my device. If you can't get LowLatency then the increase will be much higher.
We have been actively working on this problem for awhile. I will update this Issue when I have progress to report.
there seems to be several quirks with volume, volume control, etc.
See #1886
Android version(s): 6.0.1 - 14.0 Android device(s): Several Oboe version: 1.9.0
Short description I have recently used Oboe to implement an "Audio Device Module" for the WebRTC media communications stack. Generally, it works well. The sound quality and device support is really stable. The primary issue I have is that I am not getting low latency streams as much as I would have expected. I have looked at the API, FAQ, documentation, and several issues here but still can't solve it.
With the VoiceCommunication input preset and usage, 20 out of 23 devices can't obtain a low latency input stream. And for the output, 8 devices can get a Legacy low latency stream, but none of them are MMAP. At least half of my devices are capable of MMAP.
The main question here is whether or not it is possible to get more devices using low latency streams when using the VoiceCommunication setting?
Steps to reproduce I show my stream creation code here, but all of this can be reproduced with the OboeTester app.
For the format, sample rate, and channel count, I tell Oboe the format that WebRTC uses (I16, 48000Hz, 1 channel) and then ask Oboe to perform any of the conversions it needs. I understand that this can increase latency. But the conversions, if needed, have to happen, so I assume Oboe is efficient at doing so:
I also setFramesPerDataCallback() to 480 (10ms), which is also what WebRTC wants for data callbacks. Again, I know that this can increase latency but something needs to handle the buffering, and I assume Oboe would be better at it than I would be.
The sharing mode and performance mode are always set to Exclusive and LowLatency respectively, in the hopes of obtaining low latency streams:
And I am using the data callback and using shared pointers with them as advised for stability and low latency:
Now it seems we get to the problematic settings:
Setting the sessionId helps for loopback testing, but just like in https://github.com/google/oboe/issues/951, if using the AudioEffect for AEC and NS makes low latency broadly unattainable, I think we are okay using WebRTC's algorithms for them. Therefore, I have removed the sessionId setting and found that now 3 out of 23 devices I tested with can obtain a low latency input. In one case, the S22 (Exynos) could use MMAP, but without setting the SessionId, the input volume is really low/quiet.
I tried some other things:
I've also run into this issue (https://github.com/google/oboe/issues/1291). I suppose when setting the input preset to VoiceCommunication (usually) enables the AEC, so the RT Latency tests don't usually work in OboeTester.