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

Android’s 10 Millisecond Problem explained

superpowered.com

Post reply on HN
Print view View original

91–100 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#91

Post by ohitsdom »

marquis wrote: post #80
ohitsdom wrote: post #73

Is 10ms really that big of a deal? I'm an amateur musician so have some experience playing in bands, but I have a hard time believing 10ms would feel off when playing with others.

9ms is the industry-recognised time that it takes before the brain notices that sync is out. If you have 2 woodblocks clapping and they are more than 9ms out of sync, you will hear one as an echo instead of 2 blocks at the same time. So if you are a band wanting to play remotely and you have 100ms network latency plus all the other latencies of the software layer, it's not going to be possible. Similarly if you are t…

Thanks for the 9ms reference, that's helpful. I'm honestly surprised it's that low.

Re: Android’s 10 Millisecond Problem explained

#92

Post by wpietri »

TorKlingberg wrote: post #62
amelius wrote: post #48

Earlier quoted context omitted.

> There are fewer layers in it vs android. Fewer layers usually also means less flexibility.

I am not sure why this is downvoted. Abstraction layers are often added to give flexibility and ease of use, sometimes at the cost of performance. For example ALSA has features like muxing together audio from several apps, while a lower level API might only allow one app to use audio.

I think it's being downvoted because the point of abstraction layers is generally to make specific things easy at the cost of making most other things much harder. For example, Rails makes building web apps easier, but it would be much harder to make a command-line program in Rails. Ruby itself is fine for command-line programs, but there are a host of things that are impossible using it which are doable with raw C. That's why Ruby allows for C extensions: it breaks Ruby's abstractions, but restores some lost flexibility.

In that sense, flexibility and ease of use aren't synonyms; they're opposites. An open flame is flexible but not easy to use, so we have the toaster, which is easy to use but not flexible at all.

Re: Android’s 10 Millisecond Problem explained

#93

Post by ohitsdom »

masklinn wrote: post #83
ohitsdom wrote: post #73

Is 10ms really that big of a deal? I'm an amateur musician so have some experience playing in bands, but I have a hard time believing 10ms would feel off when playing with others.

The title isn't clear but (sub-) 10ms is the target . The "problem" part is that Android devices generally don't come close, the lowest-latency Android device on the market today (barring Samsung's custom "Professional Audio SDK") has a 35ms roundtrip latency (ADC -> DAC), and many devices are way beyond 100ms ( http://superpowered.com/latency/ )

This makes more sense. 100ms and over sounds to me like a huge problem, while 10ms does not.

Re: Android’s 10 Millisecond Problem explained

#94

Post by jodrellblank »

[deleted] wrote: post #67
SEJeff wrote: post #54

Earlier quoted context omitted.

Actually you have it inverted. Fewer layers means fewer abstractions. Less abstraction means you're lower level, thereby having increased flexibility. Edit: Anyone care to elaborate why the downvotes? From a technical standpoint, I'm absolutely right.

[deleted]

Heavily down voted for taking a one line comment about whether more or fewer layers of abstraction is more flexible, and using it to beat your "I hate apple" drum about terms and conditions and control and Muh Freedoms.

You're being that guy, so obsessed with a thing that you see it everywhere and think every conversation is about it.

Re: Android’s 10 Millisecond Problem explained

#95

Post by likeclockwork »

mianos wrote: post #7

Does anyone actually believe the reason " the Google Play store, the Music category is not even a top five revenue producing app category." is due to audio latency? I am not disagreeing with the fact that there is a lot of audio latency (no worse than Windows 8) but maybe it's time to explain cause vs correlation? Interesting article all the same.

It wouldn't be satisfying.

I'm an Android user and have given thought to developing on Android but the only things I'm interesting in doing on a mobile platform are synthesis and sequencing. Based on everything I've read.. it seems like it would be a waste of time. Forget commercial viability, it doesn't even sound like it would be worth it to make something for personal use. I get 7ms roundtrip on my Linux music workstation, with my audio interface, JACK, ALSA, Bitwig.. total cost maybe $1600(when buying the machine I was trying to figure out how much I could leave out/how much of a cheapskate I could be).. not a huge sum but it shows how important low latency is. A lot of the people buying music apps(synthesizers, toys) own hardware synthesizers, have computer recording/sequencing setups, or play acoustic instruments.. some of them spend multiples of 10K on their setups over time.. when they pick up a phone or a tablet, they're not comparing it to a flash site or the performance from an integrated soundcard on a $300 laptop.. they're comparing it directly to the immediate physical response of their instruments or the low-latency response of the computer audio setup they've invested in.

High latency feels incredibly sluggish and harms your sense of rhythm; unpredictable latency is just murder. Given that most makers of music software are themselves music makers.. when they pick up a device and see its audio performance is so poor the thought process is something like "If I can't even make something I would use myself on this, what's the point in trying to release something to the public?"

There are some good music apps for Android, some that I would even say are very good efforts, but they're very few, and still suffer from latency pretty badly.

Re: Android’s 10 Millisecond Problem explained

#97

Post by kazinator »

likeclockwork wrote: post #74
jannotti wrote: post #58

Earlier quoted context omitted.

Then assembly is more flexible than your favorite high-level language? It's true that you can, by definition, do more with low-level access. And I suppose that's one definition of "flexibility". But I think most developers would use the word to mean that various pieces of functionality can be put together easily. So they might say, for example, that Unix pipes are "flexible". I think I'd usually agree with that meani…

Yes, assembly is more flexible than my favorite higher level language. Because if you have access to assembly, you can implement the whatever higher level language or semantics you want. Whereas if you only have a higher level language, you have to work with/around the abstractions baked into it. For realtime applications it's better to at least have access to a low-level, less overhead API.

That is true.

For example, in assembly we can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention.

We cannot do that in C. That's because there are areas of the program state that are "off limits", and the compiler generates "GC ignorant" code.

Re: Android’s 10 Millisecond Problem explained

#98

Post by wpietri »

nsajko wrote: post #79

What downsides would there be to just halving the period size?

My guess is that the large buffers are covering up for scheduling issues. On my devices (Moto X, Nexus 7) I can regularly get Android audio to stutter by connecting the power or switching apps. (And it'll happen on its own sometimes when it picks, as it so often does, a terrible time to update apps.)

The easy fix to that is to make the buffers bigger. Doing that, though, increases latency. The hard fix is to do what Apple has done and build for audio from the ground up.

Re: Android’s 10 Millisecond Problem explained

#99

Post by CPLX »

valdiorn wrote: post #55
analog31 wrote: post #28

Earlier quoted context omitted.

Audio processing on Android devices is Slow. Even seemingly small delays (10 milliseconds) is enough to make apps seem clunky and erratic. This puts the Android platform at a disadvantage for developers whose product ideas involve delivering high quality audio performance. The embedded graph with the U shaped figure pretty much sums up the author's search for the components in the software that are the culprits.

> Even seemingly small delays (10 milliseconds) is enough to make apps seem clunky and erratic Not just that, if you try to play guitar with a 10ms latency from input to output, you'll find that it's impossible to keep rhythm at all. It's the same effect as a speech jammer: http://www.stutterbox.co.uk/ And I don't think many people outside the the tech audio community realize how many people have ditched their guitar…

If you take out the word "purely" you're absolutely right.

Few serious guitarists would resign themselves to exclusively playing through an iOS device. Nearly all serious guitarists will do it on a regular basis though, which is the more relevant point.

Re: Android’s 10 Millisecond Problem explained

#100

Post by wpietri »

mianos wrote: post #7

Does anyone actually believe the reason " the Google Play store, the Music category is not even a top five revenue producing app category." is due to audio latency? I am not disagreeing with the fact that there is a lot of audio latency (no worse than Windows 8) but maybe it's time to explain cause vs correlation? Interesting article all the same.

Perhaps you missed the section, "How Android’s 10 Millisecond Problem and Android Audio Path Latency Impacts App Developers and Android OEMs" and in particular the bullet points with specific examples of the problems high latency causes.
Post reply on HN