How to know what is the Recording Sample Rate which a device supports?

[Carlos Ferreira]

Hello!

I'm having a problem with OpenSL ES Audio Recorder.
It seems that in  <modules/audio_device/android/audio_manager.cc> the audio recorder is configured with the same sample rate used for playback. Due to this (I think)  the setup of the OpenSL Audio recorder results in a SL_RESULT_CONTENT_UNSUPPORTED for some devices. According to the Android Documentation for OpenSL, the only sample rate suited for recording that is supposed to be compatible with all devices is 16KHz, where the remaining ones may be unsupported by the device. As so, my question here is: How can I know which recording sample rate is supported by the device? Thank you!

[Henrik Andreasson]

The current implementation assumes that input uses the same native sample rate as output since that is what is recommended.

If there are some very special devices that do not support this scheme then you must probably implement something like what [1] suggests.

None of this will be added to WebRTC but you can modify and inject your own ADM if you switch to the more recent version in sdk/.

I would recommend using the Java based implementation instead since Open SL ES is now deprecated.

[1] https://stackoverflow.com/questions/8043387/android-audiorecord-supported-sampling-rates/22317382

*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*

--

---
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/7b3ec21f-d2ba-4ea1-b288-fa46e86c196an%40googlegroups.com.

[Carlos Ferreira]

Wait what? OpenSL ES is deprecated in Android? When did that happen? I though that using the JavaAudio Track was not recommended for low latency playout and recording?

[Carlos Ferreira]

FYI, I'm using WebRTC in Android but from the native side (C++).

[Henrik Andreasson]

If you need C++ support, you should implement Oboe support since it calls AAudio on newer devices and OpenSL ES on older devices. The Oboe API is a direct mapping of the C AAudio interface into C++ and you need a new ADM to support it in WebRTC. We have no plans on implementing it currently.

Don't use Open SL ES directly on all devices.

My experience is that you don't really need any native interface unless C++ is required.

Java AudioTrack has been improved over the years and can achieve almost the same performance in terms of latency as the native APIs but it also has many other benefits for VoIP applications.

You will not get the lowest latency audio path with WebRTC anyhow since we use built-in effects and that puts you off the fast track.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/72eea71f-c351-426c-8574-3a10069307f0n%40googlegroups.com.

[Carlos Ferreira]

So at the moment, what I have done was to disable OpenSL and fallback to Java AudioTrack for devices that have been reporting errors when initializing the OpenSL audio recorder.
According to what you are saying, OpenSL does not provide any extra benefit for WebRTC.
As so, it is only fair to ask, why does WebRTC still uses OpenSL? I'm asking because devices that are able to use OpenSL, will by default use it.

[Henrik Andreasson]

You are using an old (legacy ADM) which is no longer supported. Lot's of work has been done on implementing an injectable ADM for Android and iOS. See https://bugs.chromium.org/p/webrtc/issues/detail?id=7452.

The new AMD lives in sdk/ and is used by the reference demo application AppRTCMobile. It does not use Open SL ES by default.

The new (Java based) ADM is injected in the reference test client here and here.

The test client also contains: Log.w(TAG, "External OpenSLES ADM not implemented yet.");

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/33e160f5-8408-429f-87b0-e9a20e42a34an%40googlegroups.com.

[Carlos Ferreira]

Oh, I see. :)

Thank you for that information. I will take it into consideration while implementing a Fix!

[stron...@gmail.com]

Are there any documents/tests that show Java AudioTrack have similar latency as the Native API? Any special settings needed?