search

google / oboe

Oboe is a C++ library that makes it easy to build high-performance audio apps on Android.
Apache License 2.0
3.71k stars 566 forks source link

Using oboeTester's "Echo Input to Output" for a long time (more than 12 hours) without sound #1852

Closed xwdang closed 1 year ago

xwdang commented 1 year ago

Android version(s):
Android device(s): HUAWEI p40 pro
Oboe version: OboeVersion1.7.4 App name used for testing: OboeTester (Please try to reproduce the issue using the OboeTester or an Oboe sample.)

Short description Using oboeTester's "Echo Input to Output" for a long time (more than 12 hours) without sound。 This problem occurs on multiple devices

Steps to reproduce 1、open oboe Tester ， into "Echo Input to Output" 2、Click “START” button， and waitting a long time（about 12 hours） Expected behavior Playback the record sound Actual behavior no sound Device

$ for p in \ ro.product.brand ro.product.manufacturer ro.product.model \ ro.product.device ro.product.cpu.abi ro.build.description \ ro.hardware ro.hardware.chipname ro.arch "| grep aaudio"; do echo "$p = $(adb shell getprop $p)"; done ro.product.brand = HUAWEI ro.product.manufacturer = HUAWEI ro.product.model = ELS-TN00 ro.product.device = HWELS ro.product.cpu.abi = arm64-v8a ro.build.description = ELS-TN00-user 103.0.0 HUAWEIELS-TN00 215-CHN-LGRP3 release-keys ro.hardware = kirin990 ro.hardware.chipname = ro.arch = | grep aaudio = [aaudio.mmap_exclusive_policy]: [2]

robertwu1 commented 1 year ago

Seems to be an issue with buffer overflows with int32_t somewhere. Does this happen with test output or test input?

xwdang commented 1 year ago

Seems to be an issue with buffer overflows with int32_t somewhere. Does this happen with test output or test input?

Using the demo's "Echo Input to Output" will definitely appear. Tried different preset , the result is the same. Today I try to use the “test input” and “test ouput” of the OboeTester to reproduce it，and I will tell you the result later。

xwdang commented 1 year ago

Seems to be an issue with buffer overflows with int32_t somewhere. Does this happen with test output or test input?

hi, I have done a test. using oboetester, three mobile phones (there will be silent problems in the case of "echo input to output") run "test input"、"test ouput" and "echo input to output" respectively. after seven hours，the result is: 1、"test output" plays the sound normally。 2、"test input" has a progress bar for volume detection, but it does not match the actual sound. If you blow into the microphone, the progress bar will not increase significantly 3、"echo input to output" has no sound, and blowing into the microphone, the progress bar does not rise appreciably.

robertwu1 commented 1 year ago

Thanks for the feedback. It seems like there is some buffer overflow issue from the input side of things.

robertwu1 commented 1 year ago

If you get a chance, can you try test input for OpenSL ES and test input for MMAP off? This will help us determine if this is an OboeTester issue or an AAudio issue

robertwu1 commented 1 year ago

Also, can you try test Input on a non-HUAWEI phone? If this only happens with huawei phones, it may be a bug on HUAWEI

xwdang commented 1 year ago

Also, can you try test Input on a non-HUAWEI phone? If this only happens with huawei phones, it may be a bug on HUAWEI

ok, I will do these case

philburk commented 1 year ago

We ran Oboe Tester - test input on 2 Pixels. One is running 21 hours now, another one is running 16 hours. They did not stall. The VU meters were still responding.

philburk commented 1 year ago

So it is looking like a Huawei HAL bug.

xwdang commented 1 year ago

If you get a chance, can you try test input for OpenSL ES and test input for MMAP off? This will help us determine if this is an OboeTester issue or an AAudio issue

The silent problem only happened when both mmap and aaudio were open. This time only Huawei devices have problems, but the same problem has occurred on oppo and vivo devices before.

xwdang commented 1 year ago

So it is looking like a Huawei HAL bug.

I do not think so. because:

  1. Similar problems have occurred in Huawei, vivo, and oppo.
  2. I have observed that other apps that use the AAudio API directly, with the same AAudio configuration parameters, don't have this problem.
philburk commented 1 year ago

Similar problems have occurred in Huawei, vivo, and oppo.

Reopening because there is evidence that this is not a Huawei HAL bug.

xwdang commented 1 year ago

Similar problems have occurred in Huawei, vivo, and oppo.

Reopening because there is evidence that this is not a Huawei HAL bug.

Is there any progress now? Do you need my cooperation to do some tests？

philburk commented 1 year ago

Do you need my cooperation to do some tests？

We have not been able to reproduce the issue on Pixel. So we could use some more detailed information. Thanks!

For a few devices, could you please tell us: 1) Manufacturer 2) Model 3) Android version 4) Oboe version 5) How long can INput run before failing? 5) How long can OUTput run before failing? 6) Does the problem only happen with AAudio MMAP or with Legacy?

From the model, we can figure out the Chip and maybe figure out where the problem is.

Note that there may be different bugs in the HAL and in Oboe on different devices.

xwdang commented 1 year ago

Ok, I will give you these information over the weekend

xwdang commented 1 year ago

Oboe is in the master branch, commit id :fa445435372da84252f3e1cf2da6e71fdc4c09f9

I did a test with these devices，test AAudio MMAP only：

`ro.product.brand = HUAWEI ro.product.manufacturer = HUAWEI ro.product.model = SEA-AL00 ro.product.device = HWSEA ro.product.cpu.abi = arm64-v8a ro.build.description = SEA-AL00-user 102.0.0 HUAWEISEA-AL00 291-CHN-LGRP1 release-keys ro.hardware = kirin810 ro.hardware.chipname = ro.arch = | grep aaudio = aaudio.mmap_exclusive_policy: [2]

Results:

  1. After “Input” has been running for 17 hours, device a and device B appear to capture without sound, and The devices B's VU meters without responding.
  2. After “Output” has been running for 22 hours, device A、device C and device F appear to play without sound.

I don't know the specific time point when the silent problem occurs, and it seems to be irregular. I have encountered the shortest 4 hours of silence

xwdang commented 1 year ago

Do you need my cooperation to do some tests？

We have not been able to reproduce the issue on Pixel. So we could use some more detailed information. Thanks!

For a few devices, could you please tell us:

  1. Manufacturer
  2. Model
  3. Android version
  4. Oboe version
  5. How long can INput run before failing?
  6. How long can OUTput run before failing?
  7. Does the problem only happen with AAudio MMAP or with Legacy?

From the model, we can figure out the Chip and maybe figure out where the problem is.

Note that there may be different bugs in the HAL and in Oboe on different devices.

Have you found the root cause of the problem?

philburk commented 1 year ago

@xwdang - Thanks for the extra information. Based on the durations and the versions, I think the problem is due to two related bugs. At 48000 Hz, a signed 32-bit frame counter will overflow in 12.428 hours.

b/214726263 | P2 | AAudio crashes after overnight play, ALSA says "overflow in Tx/Rx" b/173531385 | P1 | AAudio MMAP has wrapping errors after overnight run

There was a numeric overflow in frameworks/av/media/libaaudio/src/utility/MonotonicCounter.h which is used to track frame counters in AAudio MMAP.

There was also a similar overflow in the Pixel HAL. There may be problems as well in other vendor HALs.

philburk commented 1 year ago

This issue was fixed in Android 13. No activity this week so closing.