oneplus 6 uses opensles through oboe, there will be no voice with mono channel capture

[lhran99]

Android version(s): Android Q ro.product.brand = OnePlus ro.product.manufacturer = OnePlus ro.product.model = ONEPLUS A6000 ro.product.device = OnePlus6 ro.product.cpu.abi = arm64-v8a ro.build.description = OnePlus6-user 10 QKQ1.190716.003 2107162030 release-keys ro.hardware = qcom ro.hardware.chipname = ro.arch = | grep aaudio = Oboe version: 1.8.0 App name used for testing: obotester

Short description ONEPLUS 6 capture no voice with opensles 48000 sample rate and mono channel using oboe. However when i change to stereo mono or set the performance mode as NONE, it will be fine.

Steps to reproduce

1. Open Oboetester, choose RECORD AND PLAY
2. set API as OpenSL ES, SRate as 48000, Channel as 1, Perf as LOW_LATENCY
3. Click RECORD to record some voice
4. Click STOP AND PLAY to replay the voice.
5. If I set channel as 2 or set the Perf as NONE
6. repeat 3~4, it can play my voice.

Expected behavior It can play the recorded voices

Actual behavior It play no voice.

I record the trace and find that, when i choose channel 2, the record hal thread callback for about 2ms

However choose channel 1, the record hal thread callback for about 100ms

Any additional context 48000_1_none.mp4.zip 48000_1_low_latency.mp4.zip

[philburk]

Thanks for this bug report, there's a few possibilities here. One is that the data path is just not working for mono low latency. The other is that the callback is too high for the burst size allocated. That can be a particular problem with OpenSL ES.

If you use TEST INPUT on this device then are you getting a signal that causes the VU meters to move?

What happens if you use AAudio instead of OpenSL?

Maybe we can add this device to the Quirk's manager.

We are adding manufacturing tests that will detect this kind of broken configuration.

[lhran99]

Thanks for this bug report, there's a few possibilities here. One is that the data path is just not working for mono low latency. The other is that the callback is too high for the burst size allocated. That can be a particular problem with OpenSL ES.

If you use TEST INPUT on this device then are you getting a signal that causes the VU meters to move?

What happens if you use AAudio instead of OpenSL?

Maybe we can add this device to the Quirk's manager.

We are adding manufacturing tests that will detect this kind of broken configuration.

If you use TEST INPUT on this device then are you getting a signal that causes the VU meters to move?

When i use TEST INPUT and select opensles ,mono channel, The VU meters get nothing. Then i select aaudio, mono channel, The VU still get nothing.

When i switch mono to stereo channel， opensles and aaudio both can get signal。

It seems that the devices has some problems with mono channel。

The screen recording is in attachment。

aaudio_48000_1.mp4.zip

https://github.com/google/oboe/assets/10515793/c8f13d70-14ef-4d3c-aebe-91a79a11fb27

[philburk]

Thanks for running that test. The fact that it fails under audio means that it is a lower level device problem. One other quick thing to check. On the oboeTesterr main screen, there is a checkbox for Oboe workarounds. Enable the workarounds and then try the test again. If it suddenly starts working then that means that this is a known quirk that we have already fixed. If it fails then it's a new quirk and we can notify Qualcomm and add this device to the quirk manager.

[lhran99]

Thanks for running that test. The fact that it fails under audio means that it is a lower level device problem. One other quick thing to check. On the oboeTesterr main screen, there is a checkbox for Oboe workarounds. Enable the workarounds and then try the test again. If it suddenly starts working then that means that this is a known quirk that we have already fixed. If it fails then it's a new quirk and we can notify Qualcomm and add this device to the quirk manager.

The capture still do not work after enable the workarounds. https://github.com/google/oboe/assets/10515793/e8c6c53c-d310-46ce-96de-ae26ee67acc7

[philburk]

Ok then we do not have an existing work around for that device. We can add it to the QuirksManager.

[lhran99]

Ok then we do not have an existing work around for that device. We can add it to the QuirksManager.

thanks