Android’s 10 Millisecond Problem explained • Hacker News Board

Re: Android’s 10 Millisecond Problem explained

#61

Post by szantog » Thu, Apr 16, 2015, 1:34 PM UTC

madez wrote: post #18

miahi wrote: post #10

Earlier quoted context omitted.

Probably by custom and known hardware. Let's say it takes 1000 working hours to produce a low latency driver/firmware; Apple only needs to do that for a few devices, but every Android manufacturer has different audio chips and most of them only care that audio works, not that it works well - so they do not invest that time for each device type. Having known hardware also works for the application developers, because…

The latency problems arise with ALSA (mostly hardware-independent) and AudioFlinger (totally hardware-independent).

ALSA is super. The HAL connecting ALSA to AudioFlinger is the major problem, plus the audio stack's "push" philosophy.

Re: Android’s 10 Millisecond Problem explained

#62

Post by TorKlingberg » Thu, Apr 16, 2015, 1:38 PM UTC

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.

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.

Re: Android’s 10 Millisecond Problem explained

#63

Post by mackey » Thu, Apr 16, 2015, 1:45 PM UTC

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

Also this:

Related presentation at Google I/O 2013. https://developers.google.com/events/io/2013/sessions/325993...

This was probably the best presentation I saw during Google I/O.

Re: Android’s 10 Millisecond Problem explained

#64

Post by vlaskovits » Thu, Apr 16, 2015, 1:46 PM UTC

Hi everyone -- Gabor and I wrote the piece -- let us know if you have any questions we can help answer for you.

Re: Android’s 10 Millisecond Problem explained

#65

Post by peterfirefly » Thu, Apr 16, 2015, 1:48 PM UTC

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.

One of the counter arguments would be that more layers of indirection lead to more flexibility.

Re: Android’s 10 Millisecond Problem explained

#66

Post by MrBra » Thu, Apr 16, 2015, 1:51 PM UTC

it looks it's currently down?

Re: Android’s 10 Millisecond Problem explained

#67

Post by [deleted] » Thu, Apr 16, 2015, 1:52 PM UTC

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.

[deleted]

Re: Android’s 10 Millisecond Problem explained

#68

Post by ctdonath » Thu, Apr 16, 2015, 1:53 PM UTC

jannotti wrote: post #58

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.

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 controls both sides of the symbiotic audio hardware & SDK running on a tiny set of products, while Android must have an SDK which accommodates an unknown range of hardware for hundreds of products, means iOS will have an inherent advantage.

Re: Android’s 10 Millisecond Problem explained

#69

Post by TillE » Thu, Apr 16, 2015, 1:54 PM UTC

creshal wrote: post #30

tim333 wrote: post #4

Earlier quoted context omitted.

Some answers on quora. TLDR Apple have been working on audio a long time. http://www.quora.com/Why-do-iPhones-have-better-professional...

Or, rather, actually care about audio. Google (/Motorola Mobility, when it was owned by it) doesn't even care if a phone ships with a broken headphone port and refuses to fix it.

Seriously, the absolute garbage headphone jacks on the two flagship Android phones I owned (Motorola Milestone and Galaxy Nexus) are the reason I now own an iPhone 6. I still mostly prefer Android as an OS, but at least Apple is willing to spend the extra 50 cents on a headphone jack that lasts for more than a couple weeks.

Re: Android’s 10 Millisecond Problem explained

#70

Post by vidarh » Thu, Apr 16, 2015, 1:54 PM UTC

madez wrote: post #13

epochwolf wrote: post #8

Earlier quoted context omitted.

By controlling the hardware, they need fewer drivers and they can skip one of the abstraction layers.

> they need fewer drivers This suggests that you can work focused on one driver and therefore save developer-time. However, the drivers on Android are made by a bigger workforce, which must be taken into account. > they can skip one of the abstraction layers The post explicitly states that the HAL ought to add no latency at all.

Besides the point. When you know the hardware you can shave away the upper layers.

Consider e.g. AmigaOS.

AmigaOS let you obtain a pointer directly to the screen bitmap to update your window contents with no buffering or clipping. It could do that because originally all the hardware was the same, or close enough.

Then graphics cards came along, and you didn't necessarily have a way of writing directly to the bitmap. Suddenly you had to use WritePixel() and ReadPixel() and similar, which would obtain the screen pointer for the window, and obtain the display the screen is on, and find the driver corresponding to the screen, and call the appropriate driver function via a jump table.

Similarly, the AmigaOS had functions to e.g. install copper lists (the copper was a very primitive co-processor that could be used to do things like change the palette at specific scan lines), which also wouldn't work at all on graphics cards.

This is why knowing the hardware is part of a limited set matters: You can define your API to match the hardware very precisely, or even expose hardware features directly.