Android version(s): 12 (58.2.A.10.126)
Android device(s): Sony XQ-AS52
Oboe version: 1.10.0
App name used for testing: my own app ("Saucillator") + Oboe Tester (i realize this may not be super helpful. i can try to share an apk if needed)
Device
ro.product.brand = Sony
ro.product.manufacturer = Sony
ro.product.model = XQ-AS52
ro.product.device = XQ-AS52
ro.product.cpu.abi = arm64-v8a
ro.build.description = XQ-AS52_EEA-user 12 58.2.A.10.126 058002A010012603718185433 release-keys
ro.hardware = qcom
ro.hardware.chipname =
ro.arch =
| grep aaudio = [aaudio.hw_burst_min_usec]: [2000]
[aaudio.mmap_exclusive_policy]: [2]
[aaudio.mmap_policy]: [2]
Summary
On a Sony Xperia, it ships with a "dynamic vibration" feature on by default (OEMs - am i right?). when this feature is enabled for an app, it causes my oboe stream to be "intercepted" in someway, appearing to work fine, but all output is silent.
an MMAP EXCLUSIVE output stream opens, starts, and runs normally, but no audio reaches the speaker. Every Oboe and AAudio API reports a healthy stream. The cause is Sony's Dynamic Vibration System, which re-routes the live mmap-playback usecase to a different output device a few milliseconds after the stream starts.
After this happens, the MMAP endpoint is left unusable. Every later EXCLUSIVE open on the device fails with -889 (AAUDIO_ERROR_UNAVAILABLE) until reboot, including OboeTester's.
Stream configuration
Direction Output
PerformanceMode LowLatency
SharingMode Exclusive
Format Float
ChannelCount Mono
SampleRate 48000
Usage Media
ContentType Music
Callback yes
The device grants 16-bit stereo. Mono and float opens fail at the HAL with -38, so AAudio falls back internally.
What happens
The stream opens and starts. AAUDIO_SERVICE_EVENT_STARTED arrives. The data callback runs at the expected rate. getXRunCount() settles at a low number and stops increasing. calculateLatencyMillis() returns plausible, varying values (17-22ms). Nothing is audible.
HAL log
The relevant lines come from audio_hw_primary in the audioserver process. 15ms after the stream starts:
start_output_stream: Starting MMAP stream
start_output_stream: exit
adev_set_parameters: enter: package_name=com.mattfeury.saucillator.android
adev_get_parameters:somc.media_vibration_path
adev_set_parameters: enter: somc.media_vibration_vol_idx=1
select_devices for use case (mmap-playback)
select_devices: changing use case mmap-playback output device from(2: speaker, acdb 15) to (134: speaker-and-vibrator, acdb 900)
disable_audio_route: reset and update mixer path: mmap-playback
onEventFromServer - got AAUDIO_SERVICE_EVENT_STARTED
disable_snd_device: snd_device(2: speaker)
enable_snd_device: snd_device(2: speaker)
enable_snd_device: snd_device(132: media-vibrator)
enable_audio_route: apply mixer and update path: mmap-playback speaker-and-vibrator
The mixer path for the running mmap-playback usecase is torn down and rebuilt with a different ACDB profile. The client already holds a direct mapping to the PCM device from out_create_mmap_buffer, so it is left writing into a buffer that is no longer routed.
Workarounds tried
Usage::Game instead of Usage::Media: no effect, still re-routed.- Stereo instead of mono: no effect.
setPackageName() / setAttributionTag(): no effect.
Questions
- In general has anyone seen this? I searched this repo and didn't see any mention, but i feel like i'm definitely on to something.
- Is there a stream configuration that avoids being claimed by this?
- Is there any way for an app to detect this at runtime? The stream reports healthy state, valid timestamps and a stable xrun count throughout.
Note on the -889 cascade
Once this occurs, the MMAP endpoint stays wedged. OboeTester then fails to start an EXCLUSIVE stream with -889 as well. A reboot clears it. This may be worth handling separately, since any app can be left unable to use MMAP by an unrelated app on the device.
Android version(s): 12 (58.2.A.10.126)
Android device(s): Sony XQ-AS52
Oboe version: 1.10.0
App name used for testing: my own app ("Saucillator") + Oboe Tester (i realize this may not be super helpful. i can try to share an apk if needed)
Device
Summary
On a Sony Xperia, it ships with a "dynamic vibration" feature on by default (OEMs - am i right?). when this feature is enabled for an app, it causes my oboe stream to be "intercepted" in someway, appearing to work fine, but all output is silent.
an MMAP EXCLUSIVE output stream opens, starts, and runs normally, but no audio reaches the speaker. Every Oboe and AAudio API reports a healthy stream. The cause is Sony's Dynamic Vibration System, which re-routes the live
mmap-playbackusecase to a different output device a few milliseconds after the stream starts.After this happens, the MMAP endpoint is left unusable. Every later EXCLUSIVE open on the device fails with -889 (
AAUDIO_ERROR_UNAVAILABLE) until reboot, including OboeTester's.Stream configuration
The device grants 16-bit stereo. Mono and float opens fail at the HAL with -38, so AAudio falls back internally.
What happens
The stream opens and starts.
AAUDIO_SERVICE_EVENT_STARTEDarrives. The data callback runs at the expected rate.getXRunCount()settles at a low number and stops increasing.calculateLatencyMillis()returns plausible, varying values (17-22ms). Nothing is audible.HAL log
The relevant lines come from
audio_hw_primaryin the audioserver process. 15ms after the stream starts:The mixer path for the running
mmap-playbackusecase is torn down and rebuilt with a different ACDB profile. The client already holds a direct mapping to the PCM device fromout_create_mmap_buffer, so it is left writing into a buffer that is no longer routed.Workarounds tried
Usage::Gameinstead ofUsage::Media: no effect, still re-routed.setPackageName()/setAttributionTag(): no effect.Questions
Note on the -889 cascade
Once this occurs, the MMAP endpoint stays wedged. OboeTester then fails to start an EXCLUSIVE stream with -889 as well. A reboot clears it. This may be worth handling separately, since any app can be left unable to use MMAP by an unrelated app on the device.