A question on input preset

[gavv]

Hi, this is just a question, not a bug report.

My goal is low-latency unprocessed input from Bluetooth and wired headsets.

I've tried different input presets with the following results:

• Generic

  Always works.

• VoiceRecognition

  Always works.

• VoiceCommunication

  The sound is distorted.

• Unprocessed

  Android 9: always works.
  Android 10: works with Bluetooth headset, doesn't work with wired headset (the stream is opened successfully, but it produces silence).

• VoicePerformance

  Android 9: doesn't work.
  Android 10: always works.

All tests were made on the same device (Xiaomi Redmi Note 7), which initially had Android 9, but was recently upgraded to Android 10.

So it seems that the most reliable input presets are Generic and VoiceRecognition.

Actually I don't see any audible difference between Generic, VoiceRecognition, Unprocessed (if it works), and VoicePerformance (if it works) on my device. The latency seems to be the same or almost the same, and AUDIO_INPUT_FLAG_FAST is always present in logs (it means that FAST path is enabled, right?).

On my device Generic works well, but my concern is portability.

---

So here are the questions:

• Does Generic guarantees that FAST path is employed?

• Can Unprocessed and VoicePerformance have any difference compared to Generic (e.g. on different devices or Android versions)?

• Is it possible to detect what modes are actually supported? E.g. to detect that VoicePerformance is not supported on this device.

• In what modes SCHED_FIFO is used in AAudio threads?

[rpattabi]

Just want to mention our experience with input presets.

Android CDD details about how certain input presets should be handled such as Voice Recognition and Unprocessed, but manufacturers don't seem to follow these specifications exactly. See issues #911 and #950.

The difference between Generic and Unprocessed is this: Generic may have AGC (Automatic Gain Control) and Unprocessed gives the raw signal without AGC and Noise Suppression.

[gavv]

@rpattabi Thanks for sharing! So it seems that Generic and VoiceRecognition can't be used to potably get unprocessed input. On the other hand, Unprocessed and VoicePerformance sometimes just don't work.

[gavv]

For now I've worked it around by retrying different presets: Unprocessed, VoicePerformance, VoiceRecognition, and Generic. If open fails, or I don't receive any input during timeout, I switch to next preset until I find a working one. So far this approach worked good for both wired and wireless headsets on Android 9 and 10.

[nguyenquynh201]

Hi guy , I don't know if you are still active, I am having the same problem and I find your solution quite good, how can I contact you?

[philburk]

I am working on answers regarding InputPreset.

In what modes SCHED_FIFO is used in AAudio threads?

SCHED_FIFO is needed to support small burst sizes. It is used for streams that have PerformanceMode::LowLatency.
Other streams will probably have SCHED_OTHER.
Note that the first callback from OpenSL ES may be on the app thread instead of the fast callback thread. So you should check the scheduler after a few callbacks have passed.

[philburk]

This patch improves the logging of the callback thread CPU scheduler in OboeTester.
#1002

It shows the initial callback from OpenSL ES using SCHED_OTHER followed by the use of SCHED_FIFO.

[philburk]

As an experiment, I converted this Issue to the new GitHub Discussions feature. Let me know how that works for you.

On my device Generic works well, but my concern is portability.

Generic (0x01) is the default InputPreset for the Java AudioRecord. So it should work pretty well on all devices.
It may have higher gain than the VoiceRecognition preset because Generic may have Automatic Gain Control.
It may also have higher latency.

Does Generic guarantees that FAST path is employed?

It was will not guarantee FAST path. But it is allowed. You may not get a FAST path if you have sample rate conversion, for example.
I was able to get LowLatency when using the InputPreset=Generic. This worked for both AAudio MMAP and Legacy paths.

Can Unprocessed and VoicePerformance have any difference compared to Generic (e.g. on different devices or Android versions)?

Is it possible to detect what modes are actually supported? E.g. to detect that VoicePerformance is not supported on this device.

VoicePerformance was added in Q 10.0. If you request VoicePerformance on earlier devices then Oboe will use VoiceRecognition instead. All InputPresets should be supported. But we are finding that the result is not consistent on all devices. We have found:

• VoiceCommunication may only work in mono. You may not get LowLatency in stereo. May also affect output paths!
• Unprocessed may be silent or have very low gain.

In what modes SCHED_FIFO is used in AAudio threads?

It should be used for the callback threads for OpenSL ES and AAudio on most devices. But some devices may use a different scheduler. The exact scheduler is not mandated.

[gavv]

Thanks for clarifications!

So it seems that I have to keep my current approach: #982 (comment). And it also makes sense to add check for very low gain, not just for complete silence.

As an experiment, I converted this Issue to the new GitHub Discussions feature. Let me know how that works for you.

Nice! Will think about enabling in in my repos too :)