Live data from Hacker News

Android’s 10 Millisecond Problem explained

superpowered.com

101–110 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#101

> “Consumers ... have a strong desire to buy such apps on Android, as shown by revenue data on iOS...” That's like saying, “Consumers have a strong desire to buy gourmet steaks from McDonald's, as shown by revenue data from Ruth's Chris.” No, McDonald's serves billions of meals by understanding its own market, not by catering to diners at Ruth's Chris. And naturally, comparing top sellers at each will give very diffe…

Analogizing McDonald's:Ruth's Chris::Android:iOS is dishonest. While I agree you can't necessarily draw that conclusion, it's like having a major (equal caliber!) seafood restaurant deciding whether to start selling steaks because Ruth's Chris is doing well. It's still apples to oranges, but it's not apples to Twinkies.

Oh come on, if you look at the major apps and games, Android gets the same things at like a six to eight month delay, if not better than that. And if you look at apps and games available on both platforms, the correlation between downloads is probably pretty good. It is nothing like apples to oranges. It's like Macintoshes to Granny Smiths.

Re: Android’s 10 Millisecond Problem explained

#102

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!

Their goal is to produce and "easily digestible overview", which necessarily means removing a lot of the detail that a hardcore performance measurement person would find interesting. They were right to stick with milliseconds throughout.

Re: Android’s 10 Millisecond Problem explained

#103
post #57
post #2

Anyone with any insight about how Apple does this?

Look at the architecture of the Core Audio API and compare it to the parent article: https://developer.apple.com/library/mac/documentation/MusicA... Besides the fact that you are writing in C/Objective C, most heavy lifting is being provided by Audio Units which are specifically designed with common datatypes to be chained, composed and executed in low-latency situations. Furthermore, most common things you would nee…

Also CoreAudio drivers (HAL) calls back every 11ms to empty/fill a buffer. So it starts with lower latency?

Re: Android’s 10 Millisecond Problem explained

#104
There is something I don't understand; maybe someone here can explain:

Sound travels at about 340 m/s (in a typical room). That means it travels about 3.4 metres in 10 milliseconds. Therefore another way to get a 10 millisecond problem is to stand 3.4 metres from the orchestra.

Most people sit farther than 3.4 metres from the orchestra, yet they don't complain about a lag between when the violin bow moves and the sound is heard. Why not?

(The speed of light is so fast that we can assume it's effectively infinite for the purposes of this argument.)

Re: Android’s 10 Millisecond Problem explained

#105
post #80

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…

IIRC it's a similar latency figure for VR headtracking (15ms), and also for touch screens (10ms).

Re: Android’s 10 Millisecond Problem explained

#106
post #104

There is something I don't understand; maybe someone here can explain: Sound travels at about 340 m/s (in a typical room). That means it travels about 3.4 metres in 10 milliseconds. Therefore another way to get a 10 millisecond problem is to stand 3.4 metres from the orchestra. Most people sit farther than 3.4 metres from the orchestra, yet they don't complain about a lag between when the violin bow moves and the sou…

Probably because they're not directly interacting with it, they're just watching it, which makes the delay a lot less noticeable. The 10ms delay is more of a problem for interactive apps where you eg. touch the screen and expect it to instantly make a sound. In this kind of feedback loop, even small delays are distracting and it becomes difficult to keep a beat because the lag is perceptible. If you tried to remotely play an instrument from 3.4 meters away, you would probably notice it too.

Re: Android’s 10 Millisecond Problem explained

#107

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…

You're ignoring the fact that speed is paramount (the whole point of the article). If you want flexibility and speed, you're going to look at using assembler (where you can do anything that can be done, running as fast as it can run) instead of a high-level language (where you have to work with packaged functionality and aggregates hiding complexity). No, it's not going to be easy. The fact that Apple totally control…

    The fact that Apple totally controls both sides of the symbiotic audio hardware & SDK running on a tiny set of products

You can use CoreAudio with third party audio hardware

Re: Android’s 10 Millisecond Problem explained

#108
post #104

There is something I don't understand; maybe someone here can explain: Sound travels at about 340 m/s (in a typical room). That means it travels about 3.4 metres in 10 milliseconds. Therefore another way to get a 10 millisecond problem is to stand 3.4 metres from the orchestra. Most people sit farther than 3.4 metres from the orchestra, yet they don't complain about a lag between when the violin bow moves and the sou…

Lag is not an issue for the listener, it's an issue for the performer. An extra 10ms of lag when wearing headphones and playing a keyboard can make you feel completely disconnected from your instrument.

Re: Android’s 10 Millisecond Problem explained

#109
post #67

Earlier quoted context omitted.

[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.

[deleted]

Re: Android’s 10 Millisecond Problem explained

#110
post #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.

Have you ever seen Rogue Amoeba's Audio Hijack for OS X?

It proves the system supports a ton of flexibility.

https://www.rogueamoeba.com/audiohijack/

Post reply on HN