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

51–60 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#51

Post by JohnBooty »

Terretta wrote: post #12

> “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…

There's a significant unit cost associated with high-quality beef; it would be literally impossible to sell at McDonalds prices.

This is not true for low-latency audio; it's just something that Android has not prioritized.

Re: Android’s 10 Millisecond Problem explained

#52

Post by stinos »

guelo wrote: post #38

Up to the ALSA driver step these delays would be the same on any Linux system. Do Linux desktop systems experience these types of delays? I have experienced these types of delays trying to setup a Windows box as karaoke machine. In fact, I've never seen a DJ use anything but a Mac. That leaves the question, how does Apple do it?

I would guess the driver model works closely together with the hardware which in practice roughly means you get samples from the ADC and put them into a buffer which is then directly accessible by the toplevel userland software. Which in turn puts output samples into a buffer which is then directly fed to the DAC. At least that is also how it works for ASIO or for example for data acquisition cards from major players like National Instruments.

Re: Android’s 10 Millisecond Problem explained

#53

Post by serve_yay »

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.

And so your preferred hypothesis is, what, everyone just forgot to write nice professional audio and music tools for Android?

Re: Android’s 10 Millisecond Problem explained

#54

Post by SEJeff »

amelius wrote: post #48
S_A_P wrote: 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.

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.

Re: Android’s 10 Millisecond Problem explained

#55

Post by valdiorn »

analog31 wrote: post #28
nness wrote: 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 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 amplifiers and are playing guitar purely through the iOS devices. It's a great use case for tablets, but is completely infeasible to do on Android at the moment.

Re: Android’s 10 Millisecond Problem explained

#56

Post by szantog »

ynniv wrote: post #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... )

Audio Flinger is not Java. On the graph you see absolutely no part which runs on Java.

Android's media architecture with it's "push" design is not more compatible than anything else with a "pull". The many layers doesn't add any flexibility, they are "only" the result of many years hacking.

Re: Android’s 10 Millisecond Problem explained

#57

Post by po »

afandian wrote: 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 need in your app like mixing, conversion, timing, etc are provided as highly optimized services by the system.

Re: Android’s 10 Millisecond Problem explained

#58

Post by jannotti »

SEJeff wrote: post #54
amelius wrote: post #48

Earlier quoted context omitted.

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

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.

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

Re: Android’s 10 Millisecond Problem explained

#59

Post by szantog »

serve_yay wrote: post #53
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.

And so your preferred hypothesis is, what, everyone just forgot to write nice professional audio and music tools for Android?

They did not forgot to write nice professional audio and music tools for Android. They can't, because of audio latency and dropouts.
Post reply on HN