Android’s 10 Millisecond Problem explained

pja wrote: post #3

afandian wrote: post #2

Anyone with any insight about how Apple does this?

Same way they do with anything else they care about: by controlling everything in the stack from the hardware up.

I don't see how this has to do with hardware rather than architectural decisions

AudioFlinger + Alsa take a lot of time, as seen per the graph

But Android seems to take the option of least effort and "works most of the time" (which they have their reasons to)

Re: Android’s 10 Millisecond Problem explained

#6

Post by easytiger » Thu, Apr 16, 2015, 11:38 AM UTC

afandian wrote: post #2

Anyone with any insight about how Apple does this?

By having their devices all roughly the same, it is easier to mitigate in app development than the variance in latency on android devices

Re: Android’s 10 Millisecond Problem explained

#7

Post by mianos » Thu, Apr 16, 2015, 11:40 AM UTC

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.

Re: Android’s 10 Millisecond Problem explained

#8

Post by epochwolf » Thu, Apr 16, 2015, 11:40 AM UTC

raverbashing wrote: post #5

pja wrote: post #3

Earlier quoted context omitted.

Same way they do with anything else they care about: by controlling everything in the stack from the hardware up.

I don't see how this has to do with hardware rather than architectural decisions AudioFlinger + Alsa take a lot of time, as seen per the graph But Android seems to take the option of least effort and "works most of the time" (which they have their reasons to)

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

Re: Android’s 10 Millisecond Problem explained

#9

Post by mhax » Thu, Apr 16, 2015, 11:43 AM UTC

raverbashing wrote: post #5

pja wrote: post #3

Earlier quoted context omitted.

Same way they do with anything else they care about: by controlling everything in the stack from the hardware up.

I don't see how this has to do with hardware rather than architectural decisions AudioFlinger + Alsa take a lot of time, as seen per the graph But Android seems to take the option of least effort and "works most of the time" (which they have their reasons to)

The hardware you intend run on will impact your architectural decisions.

Given the wide scope of hardware targeted by android, it's not that surprising that it performs less well than a system targeting a very limited set of devices.

Having said that, it performs 'well enough' for the vast majority of use cases.

Re: Android’s 10 Millisecond Problem explained

#10

Post by miahi » Thu, Apr 16, 2015, 11:45 AM UTC

afandian wrote: post #2

Anyone with any insight about how Apple does this?

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 they can optimize their code for the specific device (knowing that you always have a 40ms latency is way better than knowing that the latency is between 35 and 300ms).

Also, Apple is much more motivated to get the audio path right, having started with the iPods and selling a lot of music.