oboe icon indicating copy to clipboard operation
oboe copied to clipboard
verified publisher icon google

SM-N975F fails to produce a recording on the first attempt after boot

Open chrismanchester opened this issue 4 years ago • 6 comments

Android version(s): 12 Android device(s): SM-N975F Oboe version: 1.6.0 App name used for testing: OboeTester

Short description Input stream times out when attempting to make a recording

Steps to reproduce Restart device, plug in usb-c headset. Navigate to "Record and play" in OboeTester and press Record.

Expected behavior "Stop" followed by "Play" produces the expected recording

Actual behavior "Stop" produces and error, no recording is made

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 = samsung ro.product.manufacturer = samsung ro.product.model = SM-N975F ro.product.device = d2s ro.product.cpu.abi = arm64-v8a ro.build.description = d2sxx-user 12 SP1A.210812.016 N975FXXU7GVA5 release-keys ro.hardware = exynos9825 ro.hardware.chipname = exynos9825 ro.arch =

Any additional context

The log output during the period before the input stream times out is composed of repeated lines of:

2022-02-10 16:28:08.016 12291-14106/com.mobileer.oboetester D/AudioStreamInternalCapture_Client: processDataNow() wait for valid timestamps
2022-02-10 16:28:08.017 556-574/? E/audio_hw_proxy_9820: proxy-proxy_get_mmap_position: get_hw_ptr error invalid time stamp: File descriptor in bad state 

From attempts to find a workaround in our app I found that trying to re-start the stream immediately after a timeout is not effective, the same errors will be produced seemingly indefinitely. Trying various waits between timeout and restart the magic number seems to be about 500ms, after which everything will work as expected. This doesn't seem to be a function of time since boot either, I can leave the phone on for quite a while before trying and it will still fail on the first attempt. I can reproduce a problem in our app with OpenSL under the same conditions, but the symptom is a silent input rather than a timeout.

chrismanchester avatar Feb 11 '22 00:02 chrismanchester

The SM-975F has an Exynos 9825. Thanks for using OboeTester to reproduce the bug. Are you seeing this bug in your app as well or just in OboeTester. Is it only happening on the SM-975F? I have a Note10 Lite and could not reproduce this.

I can reproduce a problem in our app with OpenSL under the same conditions, but the symptom is a silent input rather than a timeout.

OK, that is an important clue.

It seems you are able to reproduce the but at will. Could you please generate a bugreport file? Do not attach the bugreport in GitHub. Can you file a public Buganizer bug in the audio component? Or send us the file some other way?

Please:

  • reboot the phone
  • wait 30 seconds for the logs to quiet down
  • try to record and fail
  • wait > 500 msec
  • try to record and succeed
  • take bugreport

philburk avatar Feb 11 '22 02:02 philburk

Thank you for taking a look. We tried this same procedure on several devices but were only able to reproduce on the SM-N975F. I took a bug report according to these steps and uploaded the archive to https://issuetracker.google.com/issues/218976342

chrismanchester avatar Feb 11 '22 18:02 chrismanchester

This looks like an issue specific to Samsung. A bug has been filed with Samsung: b/219815830 | [Samsung] SM-N975F fails to produce a recording on the first attempt after boot

philburk avatar Feb 15 '22 23:02 philburk

Samsung think it is related to missing permissions. I disagree because the second recording works and nothing changed as far as permissions between the first and second attempt to record.

I was able to reproduce the error on a Samsung SM-A51SF running RP1A on an exynos9611 We are continuing to investigate.

philburk avatar Apr 15 '22 18:04 philburk

We have continued trying to reproduce this issue. It may be related to a flakey USB device. What USB device were you using? Can you reproduce it consistently?

You can try:

adb logcat *:S UsbHostManager:D

then plug in your device.

philburk avatar Jul 25 '22 21:07 philburk

I was using an AKG branded usb-c headset that I believe shipped with the SM-N975F originally (details in the log below).

Unfortunately I am no longer in possession of the SM-N975F and this issue does not reproduce on my SM-G975F. At the time I was able to reproduce the bug reliably with the steps I posted.

Here is the output of adb logcat *:S UsbHostManager:D:

07-25 15:20:11.423   959  1139 D UsbHostManager: broadcasting Intent { act=com.samsung.UsbOtgCableConnection (has extras) } extras: Bundle[{Connect=On}]
07-25 15:20:11.574   959  1326 D UsbHostManager: usbDeviceAdded - start: deviceAddress=/dev/bus/usb/001/001 deviceClass=9 deviceSubclass=0
07-25 15:20:11.574   959  1326 D UsbHostManager: device class is deny listed
07-25 15:20:11.621   959  1326 D UsbHostManager: usbDeviceAdded - start: deviceAddress=/dev/bus/usb/002/001 deviceClass=9 deviceSubclass=0
07-25 15:20:11.621   959  1326 D UsbHostManager: device class is deny listed
07-25 15:20:12.472   959  1326 D UsbHostManager: usbDeviceAdded - start: deviceAddress=/dev/bus/usb/001/002 deviceClass=0 deviceSubclass=0
07-25 15:20:12.493   959  1326 D UsbHostManager: USB device attached: vidpid 04e8:a051 mfg/product/ver/serial Samsung/USBC Headset/0.05/20190816 hasAudio/HID/Storage: true/true/false
07-25 15:20:12.521   959  1326 D UsbHostManager: Added device UsbDevice[mName=/dev/bus/usb/001/002,mVendorId=1256,mProductId=41041,mClass=0,mSubclass=0,mProtocol=0,mManufacturerName=Samsung,mProductName=USBC Headset,mVersion=0.05,mSerialNumberReader=com.android.server.usb.UsbSerialReader@3abd725, mHasAudioPlayback=true, mHasAudioCapture=true, mHasMidi=false, mHasVideoCapture=false, mHasVideoPlayback=false, mConfigurations=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbConfiguration[mId=1,mName=Headset,mAttributes=160,mMaxPower=50,mInterfaces=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=0,mAlternateSetting=0,mName=null,mClass=1,mSubclass=1,mProtocol=32,mEndpoints=[]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=1,mAlternateSetting=0,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=1,mAlternateSetting=1,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=129,mAttributes=13,mMaxPacketSize=192,mInterval=1]]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=1,mAlternateSetting=2,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=129,mAttributes=13,mMaxPacketSize=288,mInterval=1]]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=2,mAlternateSetting=0,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=2,mAlternateSetting=1,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=1,mAttributes=13,mMaxPacketSize=384,mInterval=1]]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=2,mAlternateSetting=2,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=1,mAttributes=13,mMaxPacketSize=576,mInterval=1]]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=2,mAlternateSetting=3,mName=null,mClass=1,mSubclass=2,mProtocol=32,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=1,mAttributes=13,mMaxPacketSize=768,mInterval=1]]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=3,mAlternateSetting=0,mName=null,mClass=3,mSubclass=0,mProtocol=0,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=131,mAttributes=3,mMaxPacketSize=64,mInterval=8]]
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbInterface[mId=4,mAlternateSetting=0,mName=null,mClass=3,mSubclass=0,mProtocol=0,mEndpoints=[
07-25 15:20:12.521   959  1326 D UsbHostManager: UsbEndpoint[mAddress=132,mAttributes=3,mMaxPacketSize=64,mInterval=8]]]]
07-25 15:20:12.640   959  1326 D UsbHostManager: usbDeviceAdded - end

chrismanchester avatar Jul 25 '22 22:07 chrismanchester

07-25 15:20:11.621 959 1326 D UsbHostManager: usbDeviceAdded - start: deviceAddress=/dev/bus/usb/002/001 deviceClass=9 deviceSubclass=0 07-25 15:20:11.621 959 1326 D UsbHostManager: device class is deny listed

DeviceClass=9 is a hub. Maybe try without a hub. Samsung and Google could not reproduce this.

Closing as non-actionable.

philburk avatar Dec 13 '23 22:12 philburk