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

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.

from oboe.

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

from oboe.

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.

from oboe.

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

from oboe.

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

from oboe.

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

thanks

from oboe.