HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
google
oboe
C++2018–2026
google / oboe

oboe

Oboe is a C++ library that makes it easy to build high-performance audio apps on Android.

Creative & MediaMobile & DesktopLibraries & SDKs
Explore on GitHubRead Hacker News discussions
9Distinct people
12Mentions
0Explicit recommenders
4.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Oboe is a C++ library that makes it easy to build high-performance audio apps on Android.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:38:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2018-01-04 20:28:58 UTC to 2026-03-31 17:16:49 UTC.

012342018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC312
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC321
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

4 sources
pjmlp·Sep 5, 2021
https://microsoft.github.io/microsoft-ui-xaml > WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease. Apparently Microsoft does care about OOP in C++. As does Apple, https://developer.apple.com/metal/ https://developer.apple.com/documentation/driverkit And Google, https://github.com/google/oboe https://www.tensorflow.org/api_docs Maybe modern C++ is safe from OOP, so lets look into ranges, https://en.cppreference.com/w/cpp/ranges So we have factories, adaptors, concepts (aka interfaces/traits in other languages), std::ranges::view_interface as base class mixin, all stuff I can find on the Gang of
Read the rest
Four book.
In Object-Oriented Programming in C (2019) [pdf]
ArtWomb·May 1, 2021
Just getting back into Android dev myself. Rapid workflow stack: Jetpack Compose / Kotlin, Material Design UI kits and Stripe / Firebase Cloud Functions. The emphasis on being able to go from idea to release in the shortest time frame. Target being Fast Mobile Commerce https://github.com/android/compose-samples https://material.io/resources https://firebase.google.com/docs/use-cases/payments Other than that I'm excited about next-gen low latency audio library Oboe and real-time physically based renderer Filament https://github.com/google/oboe/tree/master/samples https://github.com/google/filament/tree/main/samples Best of Luck ;)
In Ask HN: What are some of must have skills for a Mobile App Developer in 2021?
donturner·Mar 11, 2021
Below is a collaborative answer from myself and my colleague, Phil Burk who is a SWE on the audio framework team. Thanks for your interest in the details of Android Latency measurement techniques. Some of the measurements were collected by third parties. We cannot describe their techniques but they are probably similar to ours. We use OboeTester to measure latency. You can find a description of how to measure Tap-to-Tone Latency and Round Trip Latency in this doc: https://github.com/google/oboe/blob/master/apps/OboeTester/d... We do not use the Larsen Effect any more because it was too sensitive to variations in gain. We now use a random encoded bit stream that sounds like a short noise burst. We can get a better correlation peak with that signal. > Many of the latency measurements break the latency down between > audio downlink and upli
Read the rest
nk. It is very hard to separate the input and output latency without special hardware (like the WALT device). You can measure combined input+output latency using a loopback test. Input latency tends to be much lower than output latency. This is because, when the full duplex stream is stable, the input buffer is close to empty and the output buffer is close to full. Then, if there is a preemption, the input buffer fills up and the output buffer drains, providing glitch protection. You can measure touch+output latency using tap-to-tone. The screen touch latency is about 15-30 msec. If you use a hardware MIDI controller (like a keyboard or drum pad) instead of tapping the touch screen then you can get a “touch” latency of about 1 msec (MIDI is a lightweight and low latency protocol). Then you can get a better estimate of just the output latency. > The android doc discusses using a GPIO to have a zero-latency signal. We don’t normally use that technique because it requires special hardware. > I found oboetester, splatency, drrickorang, and google walt. Our group supports OboeTester. > The first interesting thing is that oboetest, drrickorang, and walt seem to need an external jack-based dongle. The lowest latency path is usually over the headphone jack (either through 3.5mm or USB dongle). To test this path you do need a "jack-based dongle" aka loopback adapter. The reason why wired headphones usually give you lower latency is that OEMs often introduce digital signal processing for the speaker to improve the acoustics/quality, which can introduce additional latency. Side note: this is why you will often see "best with headphones" on games and music apps. That said, OboeTester will work over the speakers and mic in a quiet room. That is because the new random bit technique is more robust. > I'd like to script these tests. OboeTester can be scripted. We use it for continuous integration testing. https://github.com/google/oboe/blob/master/apps/OboeTester/d...
In An update on Android's audio latency
donturner·Mar 8, 2021
I'm the author. My testing methodology was to run the round-trip latency test using OboeTester: https://github.com/google/oboe/tree/master/apps/OboeTester/d.... It's a simple test: produce a tone (either on built-in speaker or over wired headphones if using a loopback dongle), measure the time it takes for that tone to reach the audio input. For devices which I didn't have access to (our team has a limited number of test devices) I used the figures from Superpowered, but with some assumptions/rules: #1 If AAudio was available on the device I used the measurements from that rather than OpenSL ES #2 No measurements from custom ROMs #3 I used the measurements from the latest version of Android which the OEM had released for that device. For example, if a device was originally released with Lollipop but it was possible to upgrade to Marshmal
Read the rest
low then I used the figures for Marshmallow. For touch screen latency measurements I used a WALT device (https://github.com/google/walt)
In An update on Android's audio latency

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.