Replies: 1 comment
-
|
OpenSL is a standardized API, while AudioTrack is a proprietary Android-only thing. And OpenSL is available through the NDK, while AudioTrack requires copying data into a Java object and then calling Java code. Technically, AudioTrack is inferior on every measure. However, Google chose to cripple Android's OpenSL implementation... which is a non-technical decision. If somebody were to submit proper code for an AudioTrack output plugin, it would be merged. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Feature Request: Android AudioTrack Output Plugin (Alternative to OpenSL ES)
Potential AdvantSummary
I would like to propose adding a native Android AudioTrack output plugin to MPD, while keeping the existing OpenSL ES output plugin available.
The goal is not to replace OpenSL ES, but to provide an alternative output path for Android devices where multi-channel PCM playback is important.
Background
Currently, MPD on Android uses the OpenSL ES output plugin ("sles").
During my testing on Android TV devices and HDMI-connected audio systems, I noticed that multi-channel LPCM content (5.1, 6.1, 7.1) does not behave as expected.
The Android audio stack is roughly:
MPD → OpenSL ES → AudioTrack / AudioFlinger → Audio HAL
In many cases, the Audio HAL and HDMI output are capable of handling multi-channel PCM, but OpenSL ES exposes only stereo PCM playback capabilities.
As a result, MPD may downmix multi-channel audio before sending it to OpenSL ES.
Why OpenSL ES Is Problematic
According to Android documentation, OpenSL ES PCM buffer queue playback is primarily designed for mono and stereo PCM.
Even when the underlying Android Audio HAL supports:
OpenSL ES may not expose those capabilities to applications.
This creates a mismatch between actual hardware capability and what MPD can output.
Many Android TV devices, media boxes, AVRs, and HDMI audio systems can accept multi-channel LPCM directly.
Examples include:
When MPD downmixes audio to stereo before output, these devices cannot receive the original surround channels.
For users whose audio systems support surround playback, downmixing is not always desirable.
In my testing, multi-channel music content often exhibits:
compared to players that preserve multi-channel PCM output.
Google has gradually shifted Android audio development toward:
OpenSL ES is effectively a legacy API and is no longer the preferred audio output path for modern Android applications.
Many Android media applications have already moved away from OpenSL ES for advanced audio playback scenarios.
Proposed Solution
Add a new Android output plugin:
audio_output {
type "audiotrack"
name "Android AudioTrack"
}
The existing OpenSL ES plugin would remain available:
audio_output {
type "sles"
name "OpenSL ES"
}
This would allow users to choose the most suitable backend.
ages
An AudioTrack backend could potentially provide:
Existing Examples
Several Android media applications already use AudioTrack as their primary output path, including:
This demonstrates that AudioTrack is a mature and practical backend for advanced Android audio playback.
Questions
I would be interested in helping test such a backend on Android TV and HDMI audio devices.
Thank you for considering this proposal.
Beta Was this translation helpful? Give feedback.
All reactions