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

201–210 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#201

Post by stinos »

jebblue wrote: post #75
rglullis wrote: post #36

Isn't this kind of a known issue in Linux land? As much as it has improved, latency has always been the bane of audio applications in the Linux kernel. I remember in the days of kernel 2.2 that even XMMS would stop playing any music if I started using more than one or two applications. Recently I got one of those cheap USB interfaces to connect my guitar. I spent some good 4 hours changing the kernel to "low latency"…

It was and I'm guessing still is a problem on Windows too: http://en.wikipedia.org/wiki/Latency_(audio) Linux has a Real Timer kernel you can run, I used to run it when doing audio stuff, it works great.

I had the exact opposite experience (about 10 years ago, didn't try any audio since on linux): even after all possible RT patches and whatnot we were happy if we would get skip-free roundtrip latencies of 50mSec on Debian with pretty much top of the line pro soundcards. Might have been bad drivers, or maybe we were just screwing up, but on Windows (with ASIO)/OsX we would just install driver, open control panel, turn down buffer size to minimum and sampling rate to maximum and be looking at about 2mSec of latency with a simple loop I->O test app (IIRC but I'm pretty sure it was 64 samples @ 96kHz)

Re: Android’s 10 Millisecond Problem explained

#202

Post by anon4 »

jblow wrote: post #139
cnvogel wrote: post #131

Earlier quoted context omitted.

ALSA is not the problem, it works very fine for the low-latency case, I can reliably run soundcards with light processing load at 96 kHz @ 64 frames/period (2 0.7ms --> 1.4 ms latency) on a quad core i5, e.g. for running a reverb effect, but most of the time I only record and will settle for 1024 frames/period or so. (2 10ms --> 20ms). The period size, just for completeness, is the number of samples recorded on each…

But ... why is there a period size? Isn't that a broken design that can only introduce latency? What is wrong with "however much audio data is ready when the application asks, send it"?

This is actually how PulseAudio attempts to work. It doesn't always work out (skype's startup sound being infamously jittery), but the thought is there.

Re: Android’s 10 Millisecond Problem explained

#203

Post by anon4 »

digi_owl wrote: post #76
rglullis wrote: post #36

Isn't this kind of a known issue in Linux land? As much as it has improved, latency has always been the bane of audio applications in the Linux kernel. I remember in the days of kernel 2.2 that even XMMS would stop playing any music if I started using more than one or two applications. Recently I got one of those cheap USB interfaces to connect my guitar. I spent some good 4 hours changing the kernel to "low latency"…

>I remember in the days of kernel 2.2 that even XMMS would stop playing any music if I started using more than one or two applications. Back then the sound subsystem didn't do any mixing or similar, so if some program grabbed /dev/snd, everyone else had to wait. As for low latency sound work on Linux today, Jack is what you want rather than pulseaudio. Frankly Pulseaudio is a massive detour when it comes to Linux aud…

You can actually layer pulseaudio on top of jack and have per-application volume controls, plus letting some applications output to your usb headset and whatnot; and also allowing pro-grade applications use jack directly, not bothering with any of the pulse nonsense at all.

Re: Android’s 10 Millisecond Problem explained

#204

Post by kllrnohj »

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

That's technically correct but an extremely inaccurate summary.

The reason ALSA and AudioFlinger add latency is to hide hardware-dependent differences as well as kernel-caused scheduling issues & policy decisions.

To achieve low-latency you need real-time scheduling, something Linux has with SCHED_FIFO but it's a bit kludgy, and getting the policy right on that is tricky (obviously you don't want a random app to be able to set a thread to SCHED_FIFO and preempt the entire system). So you have to restrict the CPU budge of a SCHED_FIFO thread, and you have to only allow apps to have a single SCHED_FIFO thread. But how much CPU time you give it needs to depend on the CPU's performance in combination with the audio buffer size that the underlying audio chip needs (and those chips also have different sample rates, is it 44.1khz or 48khz or etc...).

tl;dr: this is insanely hardware-dependent.

Re: Android’s 10 Millisecond Problem explained

#205

Post by walterbell »

kabdib wrote: post #187
weaksauce wrote: post #178

Earlier quoted context omitted.

A real postmortem of this would be a fascinating read.

Well, if something bad happens I might have to work there again, so . . . not for a few years, probably :-)

>when I finally realized what the clock root of the audio system actually was

How did you finally figure this out -- any recommended references?

Re: Android’s 10 Millisecond Problem explained

#207

Post by cdcarter »

ctdonath wrote: post #68
jannotti wrote: post #58

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…

There are a TON of third party audio interfaces that CoreAudio supports.

Re: Android’s 10 Millisecond Problem explained

#208

Post by dottrap »

This is a great description of the lowest level problem. But for those wondering why iOS doesn't have the problem or why only 10ms is such a difference, the answer is that this is only the beginning of the problem of Android audio latency.

There are still additional problems that add latency that span the entire Android stack from the actual hardware and drivers, to the kernel and scheduler, to the Android implementation of their audio APIs.

Anybody who has tried to do any serious audio on Android knows the infamous Bug 3434:

https://code.google.com/p/android/issues/detail?id=3434

Google I/O 2013 did a pretty good talk on the problem and shows how there are problems across the entire stack. Glenn Kasten pretty much carries the brunt of all the audio problems with Android. I find it telling that he had to handcraft his own latency measurement device using an oscilloscope and LED because there were no actual tools built into the OS to help them analyze performance.

https://www.youtube.com/watch?v=d3kfEeMZ65c

Audio has been terrible since Android's inception. It has improved a little over time, but unfortunately, 7 years later is is still pretty much unacceptable for any serious work.

Re: Android’s 10 Millisecond Problem explained

#209

Post by s73v3r »

Pxtl wrote: post #141

I think the article may be ascribing too much technical reasoning to why iOS has a better community of music apps - remember that Apple is also has Garage Band and dominates the online music sales business. It's fair to say that music is a core part of Apple's brand, and so the platform has a much greater draw for people who prioritize music software.

It's possible for Apple to have stuff like Garage Band because they have the ability to do low latency audio.

Re: Android’s 10 Millisecond Problem explained

#210

Post by lostgame »

JoeAltmaier wrote: post #199
lostgame wrote: post #198

The audio thing is the number one reason I will never use the Android platform. At this point, iOS devs have so many numbers of years ahead of Android devs in the music department, and the simplicity of porting existing Mac OS compatible audio stuff makes it incomparable. Metaphor: Two people are going for a race, over the same distance. One starts 5 years ahead of the other. At that point, is anyone even watching th…

Not really good metaphors. Its not necessary to cover the intervening ground, to catch up technologically. Fix latency, app developers port and voila - Android looks pretty good again.

Did you not get the '5 year head start' bit?

Doesn't matter how fast developers create applications that are amazing, iOS has already had all these years to create an already fantastic subset of these applications.

Doesn't matter how 'good' it looks - for the use case of music, android has simply lost.

Post reply on HN