Live data from Hacker News

An update on Android's audio latency

android-developers.googleblog.com

71–80 of 171 posts

Re: An update on Android's audio latency

#71

If android can get its audio latency act together there is some real opportunity here to steal market share from Apple. Since the release of the 2nd iPad Pro Apple has forced audio processing onto the slower low power CPU core, this means that for the last three years I can run all my iOS synth applications at 96kHZ with a low buffer sample size without any drop outs on my first gen iPad Pro and an iPad mini 3. What…

I've noticed an increase in measured latencies, but didn't know about that slower CPU core thing.

Sad to see Apple take such a direction - musicians appreciated having proper hardware/software and Apple definitely made money on all the paid content. Why let this arrangement fall by the wayside?

Re: An update on Android's audio latency

#72
post #25

It'd be nice if something was done about the extra 100-200ms (!!) of latency that Bluetooth headsets can add[1]. I understand this is largely a problem from the manufacturer problem, but I'd love to see Google lead the way with some sort of certification program, or even make their own low cost BT chipset for 3rd party headphones to use, to improve the situation. Of course Android is already world's better than deskt…

I've never understood why Wi-Fi latency is only 2-3ms while Bluetooth is 100-200ms when they use the same frequency band.

Is it intentional to ensure there's plenty of buffer so audio packets can be re-sent when they fail, and the audio is seamless? In other words, is 100-200ms just inherent at that frequency with expected interference?

Or is it actually just terribly designed?

Re: An update on Android's audio latency

#73
post #58

Earlier quoted context omitted.

The best I could find was https://developer.apple.com/forums/thread/71301 which suggests a 32ms touch latency. I think that might include some processing, but it doesn't seem much better than the 20ms latency in Android mentioned in the article. The audio processing latency seems to be single digit on both systems. In any case, I don't think these differences are big enough to argue that "Android can't be used for in…

Yeah, I think the numbers in the article should be good enough for a bunch of music use cases, but remember it used to be like half a second which is obviously unworkable. Well financed developers like ROLI already have instruments on android. I think the incredible instruments available on iOS are also there because the App Store promise actually kind of works for them. They write a great application, upload it to s…

Totally agree.

We should not forget that our brain is great at adjusting to latency. In the old days, when I was excessively playing Quake 3 Team Arena it took me just a couple of minutes to adjust to network latency depending on the server I was connected to.

Professional musicians do this constantly and are much better at that.

Re: An update on Android's audio latency

#74
post #37

Earlier quoted context omitted.

There will always be a niche that wants to do music production or engineering and can't afford Apple productions. Newbies or living outside the western world for example. Just because the pros have merged towards a single brand doesn't mean that the only other smartphone monopoly won't benefit greatly from offering other high quality solutions.

> There will always be a niche that wants to do music production or engineering and can't afford Apple productions. If Google cared about niches, they wouldn't have such a large graveyard of dead products - some of which were profitable and some of which were widely loved.

Caring is not a binary. A product has a much larger ongoing cost than low latency audio, so there is more of a reason to kill it.

Re: An update on Android's audio latency

#76
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)

The article and all the responses here express "latency" as a simple scalar number. Is it actually more like a histogram of values than a scalar, and the marketing number is the 90th %ile of that histogram? My impression is that Android has more latency variance than iOS. If that's true then it's important to be clear what the reported numbers represent.

If you open the audio context you should see consistent latency as long as you keep it open, but each time you open a new audio context you might end up with different latency. You should not see jitter within a single context.

Re: An update on Android's audio latency

#77
For comparison, the Nintendo Switch cardboard piano works by having you press a cardboard key with a highly reflective sticker on the other end, to lift that sticker above a barrier, so it can be seen by the game controller's integrated IR camera, which streams the image over to the switch over bluetooth, which then runs some image analysis to figure out which key sticker just became visible and THEN plays a note and the latency is STILL so much lower than on Android, that you can actually play it like a musical instrument.

Re: An update on Android's audio latency

#78
post #54
post #6

Earlier quoted context omitted.

That was a strange video. It seemed like he started talking about latency between Android and IOS devices, which makes sense given that this article talks about response time of just under 40 ms like you said. The article says this is "well within the range required for real-time applications" if you define real-time applications as non-pro-audio stuff. If you're playing an instrument and it takes 40 ms for you to he…

To be a little pedantic: He is not claiming that producers are never using PCs, he is claiming that live audio never runs on PC, because stability is the top priority there. Later he says in the studio you can tolerate a little instability if the other benefits of windows are worth it. That no producers are using windows PCs is an obviously false claim. There are DAWs that don't even run on mac. There are also live p…

> That macs are more stable in day-to-day operation is not really a bold claim though.

It absolutely is. Do you have any data to back up the claim? Anecdotally windows 10's stability seems vastly superior, especially with every release of MacOS seemingly regressing further and further.

Re: An update on Android's audio latency

#79
post #25

It'd be nice if something was done about the extra 100-200ms (!!) of latency that Bluetooth headsets can add[1]. I understand this is largely a problem from the manufacturer problem, but I'd love to see Google lead the way with some sort of certification program, or even make their own low cost BT chipset for 3rd party headphones to use, to improve the situation. Of course Android is already world's better than deskt…

I've never understood why Wi-Fi latency is only 2-3ms while Bluetooth is 100-200ms when they use the same frequency band. Is it intentional to ensure there's plenty of buffer so audio packets can be re-sent when they fail, and the audio is seamless? In other words, is 100-200ms just inherent at that frequency with expected interference? Or is it actually just terribly designed?

I'd assume a combination of larger buffers for seamless error recovery and also for lower power consumption. The receiving side of that bluetooth connection is also typically extremely battery constrained.

Re: An update on Android's audio latency

#80

Off topic, but would be nice if they could do something - presumably far simpler - about the lack of fine-grained volume control. It might be a niche case, but it's really frustrating using the various sleep-related audio apps at night with earphones and not being able to select a minimum volume that is both loud enough to hear but not so loud it keeps you awake (example: Audible with a sleep timer). I'm sure there a…

Totally agree. Fine volume control is a pain.
Post reply on HN