[Package]: Oboe

[ferrumclaudepilgrim]

Why is it worth to add this package?

Oboe is Google's C++ library for high-performance audio on Android. It wraps AAudio (Android 8.1+) with automatic fallback to OpenSL ES on older devices, handling vendor-specific quirks internally.

PulseAudio's SLES (OpenSL ES) backend has vendor-specific linking failures on a growing number of devices, each requiring a different LD_PRELOAD workaround:

• Xiaomi Poco F8 Ultra, Android 16 ([Bug]: [Pulseaudio] - OpenSL ES backend does not start due to potential linking issues #28861)
• Redmi A3, Android 16 (Audio output broken on Android 16 with PulseAudio / OpenSL ES sink #27978)
• Samsung S23/Tab S8+, One UI 6.1+ ([Bug]: PulseAudio cannot hook to OpenSL ES after One UI 6.1 update #19623)
• OnePlus 12/Nord 3, OxygenOS 15/16 (Pulseaudio does not initialize OpenSL ES on newer Oneplus devices, but only with LD_PRELOAD #27367)
• OnePlus 15, ColorOS 16 ([Bug]: PulseAudio cannot load module SLES Sink on OnePlus 15 #27357)

In #28861, the suggestion was to modify the SLES backend to use Oboe instead, since Oboe handles backend selection and vendor quirks internally. This is the same direction discussed in #29074 (the AAudio
source module PR, currently open), where the longer-term path of rewriting both PulseAudio backends with Oboe was raised.

I have a working build.sh that builds on all 4 architectures in the termux-packages Docker environment and passes on-device verification on two devices (Samsung S26 Ultra on Android 16 and Google Pixel 10
Pro on Android 17 Beta). I would like to submit a PR adding Oboe as a package if the maintainers are open to it.

Scope would be the Oboe library only. PulseAudio Oboe backend modules would be a separate follow-up PR.

Home page URL

https://github.com/google/oboe

Source code URL

https://github.com/google/oboe

Packaging policy acknowledgement

• The project is actively developed.

• The project has existing packages and is "well known".

• Licensed under an open source license.

• Not available through a language package manager: cargo, cpan, dotnet tool, gem, npm, pip, etc.

• Not taking up too much disk space (< 100MiB per architecture, exceptions can be made)

• Not duplicating the functionality of existing packages.

• Not serving hacking, malware, phishing, spamming, spying, ddos functionality.

• I certify that I have read Termux Packaging Policy and understand that my request will be denied if it is found lacking.

Additional information

I have a working build.sh that compiles cleanly on all 4 architectures in the termux-packages Docker environment. Tested on device (Samsung S26 Ultra, Android 16 and Google Pixel 10 Pro, Android 17 Beta).

Build notes:

• Builds shared library only (BUILD_SHARED_LIBS=ON)
• Includes hand-written pkg-config and CMake config files (upstream does not provide install(EXPORT) or .pc templates)
• Upstream sets -Ofast in Release builds, which triggers a deprecation warning on current clang. I did not patch it to minimize divergence.

Happy to adjust the recipe to whatever conventions maintainers prefer.

[robertkirkman]

Scope would be the Oboe library only. PulseAudio Oboe backend modules would be a separate follow-up PR.

Thank you! Please feel free to open a PR with any amount of work in it, but also note that ideally, I would love to see a complete example of Pulseaudio or at least one other program being able to use Oboe in Termux, as an example to test with, before merging the PR

[robertkirkman]

For example: I've heard that the package openal-soft can possibly benefit from Oboe, If possible, i'd like you to try to configure openal-soft to Oboe mode with your Oboe and see if it works and if so, how well and how it compares to the current OpenSL ES mode used by openal-soft,

Does that sound like something you'd be interested in?

[ferrumclaudepilgrim]

Absolutely, went ahead and tested it.

When I started looking at packaging Oboe I spent a good amount of
time going through the related issues and PRs to understand where
the pain points actually were. The suggestion in #28861 about
modifying the SLES backend to use Oboe, the vendor-specific
linking failures across Samsung (#19623), Xiaomi (#28861, #27978),
and OnePlus (#27367, #27357), each needing a different LD_PRELOAD
workaround. Then I found your work on the openal-soft side with
#23149, #23185, and the upstream thread at kcat/openal-soft#1111.
Same root cause showing up in different places.

So when you asked about openal-soft it was already on my radar.
Built it in the Docker environment with two changes to build.sh:

• Added oboe to TERMUX_PKG_DEPENDS
• Added -DALSOFT_REQUIRE_OBOE=ON to EXTRA_CONFIGURE_ARGS

Upstream's existing backend (alc/backends/oboe.cpp) picks up our
package via find_package(oboe) and compiles right in. No patches.

Tested on 2 devices:

S26 Ultra (Android 16) and Pixel 10 Pro (Android 17 Beta):
Oboe: initialized, played audio, 48kHz stereo, 0 XRuns
OpenSL ES: both hit undefined symbol: swift_demangle

Same error, 2 vendors, 2 Android versions. readelf confirms
libopenal.so links liboboe.so as a runtime dependency.

Happy to include the openal-soft change in the Oboe PR or file
it as a separate enhance(main/openal-soft), whatever works best
for you.

[robertkirkman]

Yes please include that in the Oboe PR

[robertkirkman]

If you don't mind me asking, @ferrumclaudepilgrim , if you are an openclaw, then how did you test your build of openal-soft on Galaxy S26 Ultra and Pixel 10 Pro? Do you have access to those devices?

[ferrumclaudepilgrim]

I am not on OpenClaw. Most of my work and testing happens on my personal device Samsung s26 Ultra. I have the Pixel 10 Pro I got as a throwaway/ free phone from T-Mobile when I switched and I have been way too deep into trying to learn as much as I can. My accounts are weird I know and it looks odd. I created this Github account to operate on my phone to try and separate work because it was giving me a headache. Turns out its creating more of a headache than I thought. I am testing after build by iteating and building a test script with Claude Code then running the scripts. This Oboe example I had it play audio that I confirmed I heard. We tested the mic A/B no audio v me speaking into the mic and other stuff. They are my personal devices. I have an OpenClaw instance deployed (kind of). When I was building it I made a slight deviation from build docs and paid for it later. It's partially shelved/ on the back burner.

Some of my previous comments may have caused confusion. I can assure you I am a 40 year old dude with a GED and Claude Max 20x subscription who is way to into trying to learn my tail off and have fun/ contribute along the way. So far its pretty fun/ exciting/ enfuriating/ and I am learning from that horrible attempt at a squash to now lol.

[robertkirkman]

That's completely fine, sorry for misinterpreting the account, the bio of the account really makes it sound like it is claiming to be a claude code instance. It's good to hear that Oboe makes openal-soft work better, since I had been hoping it would but I had not tried yet. I'm looking forward to using it!

[ferrumclaudepilgrim]

I see you approved the PR on your side. Good to see it appears
to be working on your end as well.

While I was digging through all of this I spent a good bit of
time going through the audio side of things in Termux. The SLES
issues across different vendors, the AAudio modules, how
PulseAudio handles its backends. From what I can tell the longer
term picture looks something like PulseAudio Oboe modules (sink
and source) replacing the SLES backend, which would also make
the AAudio modules (including my #29074) less necessary over
time since Oboe handles both directions internally. That path
seems like it solves multiple open issues and from what I have
read that is the direction things were headed.

Speaking of #29074, I noticed it has been sitting with approval
for a bit. Curious if there is anything blocking it or if it is
queue timing. Not pushing, just want to make sure I am not
missing something I should be doing on my end.

PulseAudio Oboe modules feel like the natural next step in my
head. If building them would be useful to the repo I am happy
to put the time and effort in as it is a win/win for the repo
and me learning. Any ideas, guidance, whatever you have is
appreciated. I have thick skin and am just overall friendly and
looking to help.

Thank you for the back and forth on all of this. It has been a
great learning experience and I want to keep that going.

[ferrumclaudepilgrim]

Side note no biggie about misinterpreting the account. After reading it from a different perspective I can definitely see how that appears to be the case.

[robertkirkman]

noticed it has been sitting with approval
for a bit. Curious if there is anything blocking it or if it is
queue timing.

these PRs will affect a lot of packages, potentially, so should receive approvals from multiple people before being merged.

[ferrumclaudepilgrim]

Perfect. My read on it was the more it touches the more eyes on it. Wanted to make sure that was right. Thanks again as always!