Live data from Hacker News

Android’s 10 Millisecond Problem explained

superpowered.com

41–50 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#41
post #16
post #14

This squares pretty well with my personal experience. Pretty much every music geek I know chose an iPhone over an Android because of the music apps

I'm a music geek, I just chose to carry a dedicated music player.

Yeah I wasn't talking about that kind of music geek :)

There are some pretty great instrument apps available for the iphone, like the ikaossilator by korg, a tonne of great drum machines, loop apps, synths etc. And mixed with the Audiobus app that lets you route the sound of one app into the input of another (as long as both apps support Audiobus which most seem to do), the possibilities for creating music entirely on your phone are limitless

Re: Android’s 10 Millisecond Problem explained

#42
If you’re interested in this topic, you should listen to episode 20 of the Android Developers Backstage podcast. [1]

Raph Levien talks about audio latency and how they started working on minimising it in Lollipop. He mentions that it’s still an ongoing process.

The relevant part starts at 35 minutes into the episode.

[1]: http://androidbackstage.blogspot.com/2015/01/episode-20-font...

Re: Android’s 10 Millisecond Problem explained

#43
Reading about this takes me back to the late 90s. I had just gotten serious about recording music on my computer and purchased an 866mhz dell pc. I was a using windows 98 and ASIO was still mostly a Steinberg only development and I couldn't afford cubase. I got a hand me down version of cakewalk pro audio 8. I remember the latency of that set up was about 35ms and thinking this is pretty good. There was some degree of having to start playing just slightly early so you could stay on time. With guitar and keys this was doable but I'm sure it would have been maddening with drums. I think it was when fl studio 3 came out that I had the first "daw" that supported ASIO. I remember being blown away at how much tighter everything sounded from that point on.

For those interested in why iOS is better than android, a good summary would just be to say Core Audio was designed from the ground up to be a low level low latency audio API. There are fewer layers in it vs android. When designing OS X Apple knew they had a large professional media market so that got priority. I am interested to see the results of these guys efforts and have wondered when an ASIO equivalent would pop up for android.

Re: Android’s 10 Millisecond Problem explained

#44
post #43

Reading about this takes me back to the late 90s. I had just gotten serious about recording music on my computer and purchased an 866mhz dell pc. I was a using windows 98 and ASIO was still mostly a Steinberg only development and I couldn't afford cubase. I got a hand me down version of cakewalk pro audio 8. I remember the latency of that set up was about 35ms and thinking this is pretty good. There was some degree o…

Thank you, that's exactly what I was wondering. I didn't see anything in the article that gave good reasons for why iOS would be a significant improvement.

Re: Android’s 10 Millisecond Problem explained

#45
post #20

Can someone explain in layman's what the issue actually is, because the article, neither its comments here or on Reddit, seem to dumb it down for non audiophiles?

Audio processing in Android is low-priority, highly layered and each layer has extensive buffers. This means samples take a long time to move through layers, and as these delays accumulate you end up with fairly big and definitely noticeable audio latencies.

This is obviously an issue when doing real-time audio processing or generation: if you're using virtual instruments and the feedback to your cans is 1/10th of a second behind the interaction it's unusable.

But it's also a problem for more mundane applications: a 200ms roundtrip (100ms to move samples from the mic to the application on the talker's side, and 100ms to move them from the application to the speaker on the listener's side) is is more delay than the transmission time from somebody literally on the other side of the earth. Same with fast-paced game, audio feedback >100ms after an action is highly bothersome or even game-breaking (the sound is output several frames behind the gamestate)

Re: Android’s 10 Millisecond Problem explained

#46
post #21

This is a pet peeve of mine. Hackers, when measuring time for software performance, please use something smaller than milliseconds. 0ms is a Dirty Lie!

In this case the performance measure in question is whether the latency is perceptible to humans or not. Milliseconds is the appropriate unit. Nobody is going to notice differences of less than 1ms.

Well, e.g. 20x 0.4ms (rounded to 0ms) is going to be noticed quite soon.

Re: Android’s 10 Millisecond Problem explained

#47
post #34
post #21

Earlier quoted context omitted.

In this case the performance measure in question is whether the latency is perceptible to humans or not. Milliseconds is the appropriate unit. Nobody is going to notice differences of less than 1ms.

Accumulation. If x is the unit of measure for the end-result and we have n components that add together, then we need at least x/n as unit of measure for the performance of each component. x/(2*n) is more reasonable to not deviate from the target performance more than one x after rounding in the worst-case.

Yes. But if some of your stages have delays of tens of milliseconds then there's no point knowing how big the delays are in the stages that are lower than 1 millisecond.

Once they're all below 1ms it's worth increasing the resolution.

Re: Android’s 10 Millisecond Problem explained

#48
post #43

Reading about this takes me back to the late 90s. I had just gotten serious about recording music on my computer and purchased an 866mhz dell pc. I was a using windows 98 and ASIO was still mostly a Steinberg only development and I couldn't afford cubase. I got a hand me down version of cakewalk pro audio 8. I remember the latency of that set up was about 35ms and thinking this is pretty good. There was some degree o…

> There are fewer layers in it vs android.

Fewer layers usually also means less flexibility.

Re: Android’s 10 Millisecond Problem explained

#49
TL;DR the Linux layer (ALSA) and the Java layer (Audio Flinger) use widely compatible but high latency techniques, whereas Apple designed their API's and hardware such that these layers can be optimized to almost nothing. (From the article: http://superpowered.com/wp-content/uploads/2015/04/Android-A...)
Post reply on HN