Galaxy A15 - When InputPreset is set to VoiceCommunication, audio data from the microphone is blank.

[KeigoHisazumiTest]

Android version(s): 14
Android device(s): Galaxy A15 (SM-A156E)
Oboe version: 1.9.0, 1.7.0
App name used for testing: OboeTester

Short description
On a Galaxy A15, when you select "RECORD AND PLAY" in OboeTester and the InputPreset is set to VoiceCommunication, the audio data coming from the input callback is empty.

Steps to reproduce

1. Start OboeTester
2. Press 'RECORD AND PLAY'
3. Select InPreset "VoiceComm"
4. Press 'RECORD'
5. Speak into device
6. Press 'STOP'
7. Press 'PLAY'

Expected behavior
Step4: VolumeBar is working
Step7: Can hear the audio

Actual behavior
Step4: VolumeBar not working
Step7: Cannot hear the audio

Device
Galaxy A15 (SM-A156E) - Android 14

ro.product.brand = samsung
ro.product.manufacturer = samsung
ro.product.model = SM-A156E
ro.product.device = a15x
ro.product.cpu.abi = arm64-v8a
ro.build.description = a15xnsdxx-user 14 UP1A.231005.007 A156EDXS1AXA4 release-keys
ro.hardware = mt6835
ro.hardware.chipname =
ro.arch =
| grep aaudio = [aaudio.mmap_exclusive_policy]: [2]
[aaudio.mmap_policy]: [2]

Any additional context
・Tried changing all the settings that can be made with OboeTester, but there was no improvement.
・Checked the audio data variables immediately after the callback was called, and they were all set to 0.
　https://github.com/google/oboe/blob/main/src/common/AudioStream.cpp#L62
・When InputPreset was set to anything other than VoiceCommunication(such as VoiceRecognition), audio data was received.
・Able to make calls using a voice calling app (FaceBook Messanger) that uses the oboe.
　・Particularly noteworthy once we use FaceBook Messenger, the problem does not reoccur on OboeTester.
　・The problem reoccurred after resetting the device.

[KeigoHisazumiTest]

Although I have not been able to test this on my own, the same problem can occur on the following devices:

SCG02     Galaxy S20+
SM-S908E  Galaxy S22 Ultra
NE2211    OnePlus 10 Pro
XT2215    moto g stylus

[philburk]

@KeigoHisazumiTest - Thanks for reporting this!

Is the input stream using "MMAP" or "Legacy"?

Try turning off the MMAP checkbox. Does that enable recording?

Try changing mono/stereo. Any difference?

[philburk]

The Galaxy S20+ uses "Exynos 990 (7 nm+) - Global
Qualcomm SM8250 Snapdragon 865 5G (7 nm+) - USA"

The Galaxy A15 5G, SM-A156E uses "Mediatek Dimensity 6100+ (6 nm)"

OnePlus 10 Pro uses "Qualcomm SM8450 Snapdragon 8 Gen 1 (4 nm)"

So this does not seem to related to a specific chipset or HAL!

[philburk]

I tried to reproduce this on a Nothing phone running U2.240628.0430 but it worked OK.
I rebooted the phone before testing.
It has a QCOM SM8475.
OboeTester V2.7.1

[philburk]

@KeigoHisazumiTest - Is this intermittent or does it happen every time after a reboot?

[tkksato]

Hi, @philburk Thanks for investigating the issue.

I am on the same development team as @KeigoHisazumiTest. He will not be able to answer for a while so I will answer for him.

Is the input stream using "MMAP" or "Legacy"?
Try turning off the MMAP checkbox. Does that enable recording?

The input stream uses MMAP.
Sorry, I don't have the device on hand to try switching to Legacy.

Is this intermittent or does it happen every time after a reboot?

It happens every time after factory resetting, but once it is resolved, it cannot be reproduced by simply rebooting the device.

[philburk]

@tkksato - Thanks for the new information. I am trying to get a Samsung S20+.

The input stream uses MMAP.

Oh! That is interesting. On my Pixel phone it is Legacy.

It happens every time after factory resetting, but once it is resolved, it cannot be reproduced by simply rebooting the device.

Wow! That is a big clue. Not sure what it means but it means something.
I Factory Reset my Comet running Dec 2 build.
The test passed, I could record.

When the bug is happening, can you please enter on the host:

adb shell dumpsys audio >~/dumpsys_audio_bad.txt

then attach the text file to this bug?

Then when the bug has stopped happening do the same but create dumpsys_audio_good.txt
Then we can compare them. Thanks!

[robertwu1]

I tried this on my personal Samsung Z Fold 4 on Android UP1A.231005.007 and I couldn't repro this after rebooting. I'm not factor resetting this phone to test this.

[philburk]

jmtrivi says we should look for something like:

12-10 15:36:28:317 rec start riid:5311 uid:10400 session:2657 src:VOICE_COMMUNICATION not silenced pack:com.mobileer.oboetester
12-10 15:36:32:362 rec stop riid:5311 uid:10400 session:2657 src:VOICE_COMMUNICATION not silenced pack:com.mobileer.oboetester

[tkksato]

@philburk

I was able to get a log of when the issue occurred.
Could you please check?

dumpsys_audio_bad_mmap_on.txt

In addition, I am attaching a screenshot of that time.

[screenshot when the issue occurred]

[tkksato]

Try turning off the MMAP checkbox. Does that enable recording?

I tried turning off the MMAP checkbox, but the audio data remained empty as when it was on.
I have attached a screenshot and log of that as well.

dumpsys_audio_bad_mmap_off.txt

[screenshot when the issue occurred after turning off MMAP checkbox]

[philburk]

I tried this on a Galaxy S20+5G running TP1A.220624.014 right after a factory data reset.
I could not reproduce the bug. It recorded my voice.
I did not enable Hot Word detection.

Jiabin suggested that the mic may be left in a bad state after Hot Word training.

[philburk]

From the screenshots above I can see that in both cases the MMAP was not used.
In one, the MMAP was requested, but it was followed by a "NO" and the Stream status says "Legacy".

Events log: recording activity received by AudioService
12-11 14:02:50:493 rec update riid:447 uid:10304 session:545 src:VOICE_COMMUNICATION not silenced pack:com.mobileer.oboetester
12-11 14:02:58:514 rec stop riid:447 uid:10304 session:545 src:VOICE_COMMUNICATION not silenced pack:com.mobileer.oboetester
12-11 14:11:41:066 rec update riid:511 uid:10304 session:633 src:VOICE_COMMUNICATION not silenced pack:com.mobileer.oboetester
12-11 14:11:47:424 rec stop riid:511 uid:10304 session:633 src:VOICE_COMMUNICATION not silenced pack:com.mobileer.oboetester

It is interesting that we are seeing "rec update" and not "rec start".

@tkksato - Could I ask another favor? Could you capture a different dumpsys WHILE the bug is happening and the audio is recording. You can just leave MMAP enabled. It won't make any difference.

adb shell dumpsys media.audio_flinger >~/dumpsys_audio_flinger_bad.txt

Also have ever you seen this bug on Android 15?

After a factory data reset, do you enable, or train the Hot Word detector?

[flamme]

The input stream uses MMAP.

From the screenshot above, both were using legacy path. Even the MMAP checkbox is checked, MMAP was not used. If MMAP is used, the word next to MMAP checkbox after opening the stream should be YES

[tkksato]

@philburk @flamme
I was mistaken about MMAP, my apologies. 🙇‍♂

I got media.audio_finger logs.
I am attaching the logs when the MMAP checkbox is ON and OFF.

dumpsys_audio_flinger_bad_mmap_on.txt
dumpsys_audio_flinger_bad_mmap_off.txt

[tkksato]

@philburk @flamme

I got the log before STOP RECORDING. I am attaching this as well.
dumpsys_audio_flinger_bad_on_recording_mmap_on.txt

[flamme]

I was mistaken about MMAP, my apologies. 🙇‍♂

No problem at all!

Thanks for sharing the dump of audio flinger!

From the audio dump, the recording was not silenced by the framework. But there is no signal power history, which indicates that the data read from the HAL was all silence. But given it happened on couple different device/chipset/HAL implementation, I suspected there could be some command sent to the HAL that caused the HAL sending silent data.

    Active     Id Client Session Port Id  S  Flags   Format Chn mask  SRate Source   Server FrmCnt FrmRdy Sil   Latency
       yes     93  23166    1105      75  A  0x000 00000005 0000000C  48000      7 0003CB40   2880      0   n   23.81 t

[flamme]

Created internal bug b/383778808 for discussion. Will need to reproduce on our side and generate a full bugreport for further investigation.

[tkksato]

@philburk @flamme
Thank you!!
I will continue to cooperate with the investigation.