Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on Android's audio latency

android-developers.googleblog.com

Post reply on HN
Print view View original

41–50 of 171 posts

Re: An update on Android's audio latency

#41

Post by jefftk »

thomasahle wrote: post #36
jefftk wrote: post #17

This is way better than it used to be (I measured half a second latency in 2012: https://www.jefftk.com/p/android-sound-synthesis-and-latency ) but it is still too high to let you use an Android device as a musical instrument. This is something iPhones have always been able to do, and one of my biggest disappointments with Android. (Disclosure: I work for Google, speaking only for myself)

What are the equivalent numbers for iPhone? Touch to audio and round-trip times?

https://superpowered.com/latency has messy data, but it looks like typically single-digit latency.

Re: An update on Android's audio latency

#42

Post by fireattack »

leecb wrote: post #21
AndrewDucker wrote: post #15

What's the equivalent latency on an iPhone?

The most common results on this page indicate that it varies with buffer size, but could be 9-11 ms for iPhones. https://superpowered.com/latency

I feel like their app (or method) is flawed in some way. It can't be that many phones have 300~400ms+ latency!?

Re: An update on Android's audio latency

#43

Post by jancsika »

raphlinus wrote: post #29
AceJohnny2 wrote: post #2

Usually, "an update on [blank]" is euphemism for said product getting cancelled. More to the point, one of PulseAudio's claims was that they consumed less CPU than Android's audio pipeline. With the recent hyped PipeWire, I wonder how that compares to Android's Oboe.

That's actually the joke here, which got a chuckle out of me. The idea is that excessively large audio latency itself has gotten cancelled. I haven't played with it myself (it's been a few years since I was actively involved in Android audio latency), but from what I've seen, AAudio is pretty good, probably close to what the hardware is capable of. I'd very much encourage people to do empirical measurements against,…

> I'd very much encourage people to do empirical measurements against, for example, PipeWire (which also looks good).

A rule of thumb from reading linux audio mailing lists but which probably works generally-- completely disregard any claim of measurement of latency that isn't prefixed.

For example, the Google blog labels the Y-axis with "round-trip time in milliseconds." They're clearly and explicitly measuring round-trip latency. They then piggy-back on that well-understood concept to introduce the concept of "tap-to-tone latency" and show measurements for that.

Almost to the case, the times I've read a back-and-forth conversation where the word "latency" is used unprefixed, the commenters might as well be describing the warmth of vinyl recordings. Often they are simply describing an integer they typed into a widget or config file.

On several occasions I've witnessed users insert Jack between a single application and ALSA because "that's what the professionals use." These are knowledgeable users who want as little latency between the system and their ear as possible.

Re: An update on Android's audio latency

#44

Post by limeblack »

jefftk wrote: post #17

This is way better than it used to be (I measured half a second latency in 2012: https://www.jefftk.com/p/android-sound-synthesis-and-latency ) but it is still too high to let you use an Android device as a musical instrument. This is something iPhones have always been able to do, and one of my biggest disappointments with Android. (Disclosure: I work for Google, speaking only for myself)

I agree audio at minimum should have been done differently on Android.

The latency(different type I believe) of Spotify applications and even YouTube applications is pretty bad compared to an Apple device. Sometimes the audio just fails to respond for half a second or so. This is not an interface bug from my experience.

Re: An update on Android's audio latency

#45

Post by Robotbeat »

Responsiveness and low input-to-result latency was why I chose iPhone over android 10 years ago even though I prefer a more open environment like android. Sounds like things haven’t changed a whole lot on that front.

Sometimes I wonder if these increased levels of abstraction and even digitization itself (or at least the Internet-ization of things) is a mistake for human-machine interface. Watching drone racing pilots use analog controls and analog video headsets in spite of the potato resolution because WiFi/digital/etc just add too much latency is kind of eye opening and makes you sort of reconsider the last couple decades. (Improvements have been made so digital isn’t so high latency and VR has served to address a lot of these latency concerns, but it’s still kind of interesting...)

Re: An update on Android's audio latency

#46

Post by alpb »

AceJohnny2 wrote: post #2

Usually, "an update on [blank]" is euphemism for said product getting cancelled. More to the point, one of PulseAudio's claims was that they consumed less CPU than Android's audio pipeline. With the recent hyped PipeWire, I wonder how that compares to Android's Oboe.

At Google it typically manifests itself as "Advancing our amazing bet" https://news.ycombinator.com/item?id=12792928

Re: An update on Android's audio latency

#47

Post by S_A_P »

jefftk wrote: post #41
thomasahle wrote: post #36

Earlier quoted context omitted.

What are the equivalent numbers for iPhone? Touch to audio and round-trip times?

https://superpowered.com/latency has messy data, but it looks like typically single-digit latency.

I think typical newish (2014+) devices have between 5-9ms latency. Having core audio from the start was a huge leg up for iOS for sure. I am mostly platform agnostic unless I am working with audio where I pretty much only use Apple products.

Re: An update on Android's audio latency

#49

Post by micv »

zachruss92 wrote: post #30
ocdtrekkie wrote: post #23

Earlier quoted context omitted.

This is where Apple's far superior product lifecycle comes in: Buying a four year old Apple product is affordable, still runs the current OS, unlike Androids that old, and has the audio performance down.

This is a valid point, but it’s hard to place the blame on Google/Android. I think the challenge is less of Android itself but a refusal of the OEMs to support newer OS versions. This makes business sense, but sucks for consumers. I think Google is doing a better job with their Pixel devices. I honestly hope they try to lead the Android industry more with them.

A four year old Android is years out of support to Googlew. You get two, maybe three, years from them at best and then security patches until they get bored.
Post reply on HN