Developing with the NDK will not solve this problem? Does it still have to go through alsa and audioflinger?
Android’s 10 Millisecond Problem explained
11–20 of 311 posts
Re: Android’s 10 Millisecond Problem explained
#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 different lists.
Re: Android’s 10 Millisecond Problem explained
#13Earlier quoted context omitted.
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.
> 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.
Re: Android’s 10 Millisecond Problem explained
#14This squares pretty well with my personal experience. Pretty much every music geek I know chose an iPhone over an Android because of the music apps
Re: Android’s 10 Millisecond Problem explained
#15Developing with the NDK will not solve this problem? Does it still have to go through alsa and audioflinger?
Even if you write an application in C for a GNU/Linux distribution you have to use whatever sound Linux-subsystem is deployed, unless you have root permissions and want to mess concurrently with the audio stack (you don't).
The problem is not the fact that they use ALSA and AudioFlinger. ALSA and AudioFlinger just use at this moment too much time. This could be improved by decreasing the period size.
Re: Android’s 10 Millisecond Problem explained
#16This squares pretty well with my personal experience. Pretty much every music geek I know chose an iPhone over an Android because of the music apps
I'm a music geek, I just chose to carry a dedicated music player.
Re: Android’s 10 Millisecond Problem explained
#17This is a pet peeve of mine. Hackers, when measuring time for software performance, please use something smaller than milliseconds. 0ms is a Dirty Lie!
Re: Android’s 10 Millisecond Problem explained
#18Anyone 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…
The latency problems arise with ALSA (mostly hardware-independent) and AudioFlinger (totally hardware-independent).
Re: Android’s 10 Millisecond Problem explained
#19This squares pretty well with my personal experience. Pretty much every music geek I know chose an iPhone over an Android because of the music apps
I'm a music geek, I just chose to carry a dedicated music player.
The issue isn't about having your phone play music, it's about you playing music on your phone, in some cases with friends who play on their own phones.
Re: Android’s 10 Millisecond Problem explained
#20Can 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?