Live data from Hacker News

Android’s 10 Millisecond Problem explained

superpowered.com

151–160 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#151

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

Trying to make Pulse work is a big mistake. The first step on any Linux setup is ensuring that it isn't installed. One can get very short latency out of Alsa, up to the point where the hardware becomes your bottleneck. But that's extremely processor intensive, and won't work well if you try to share the dsp with several processes (if you want to get that extreme, I'd recommend you get extra hardware for exclusive use…

I am talking about my day-to-day workstation and laptop running (x)ubuntu. Pulse may not be great, but nowadays I get to use Skype, watch videos, and listen to music all day using Pulse... why should I go through all the trouble of removing it if it works for the most common tasks?

About the interface. I doubt that was the problem. When I got jack to work, I was getting 2-3ms latency between input and processed output. I did get the guitar effect application to work, I just thought it was too inconvenient to be forced to be aware of "what-application-uses-what-sound-system-and-when-I-need-to-flip-the-switches".

In any case, my goal was to have a alternative that could be (a) cheap and (b) convenient if I wanted to play with my guitar and have some DAW tools, not to see how low I could bring down latency in a linux system. The lesson learned is that it can be cheap, but not convenient.

Ps: did you go to Unicamp?

Re: Android’s 10 Millisecond Problem explained

#152
post #139

Earlier quoted context omitted.

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"?

Well... it's like all audio chipsets work nowadays. Only some DSPs will be able to efficiently handle single-frame data processing, but they have the help of dedicated address generators and lightweight interrupts synchronized to the digital interface. If you write "process however much audio data is ready", then you already imply that your CPU will not be up to speed to process 48000 interrupts/second reliably and y…

As someone who has actually done a good amount of soft-real-time audio programming, I can tell that you probably haven't. Everything you are saying about CPU speeds is made-up nonsense. Look into how these things are done on systems where folks actually care about latency (for example, commercial audio hardware, game consoles, etc).

Re: Android’s 10 Millisecond Problem explained

#153
post #152

Earlier quoted context omitted.

Well... it's like all audio chipsets work nowadays. Only some DSPs will be able to efficiently handle single-frame data processing, but they have the help of dedicated address generators and lightweight interrupts synchronized to the digital interface. If you write "process however much audio data is ready", then you already imply that your CPU will not be up to speed to process 48000 interrupts/second reliably and y…

As someone who has actually done a good amount of soft-real-time audio programming, I can tell that you probably haven't. Everything you are saying about CPU speeds is made-up nonsense. Look into how these things are done on systems where folks actually care about latency (for example, commercial audio hardware, game consoles, etc).

Please tell me what claim I made about CPU speeds is unsubstantiated nonsense?

Re: Android’s 10 Millisecond Problem explained

#154
post #48

Earlier quoted context omitted.

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

iOS can mix audio while preserving low latency. It works much better because CoreAudio is basically a full audio routing and mixing engine and forces more realtime-ish requirements on implementations. The system level engine just takes audio from apps as if they were submixers.

None of that stops you from having a high-level API on top, and in fact iOS has several at different levels of abstraction: AVAudioEngine gives you a lighter weight but object-oriented engine that's less complex to setup. AVAudioPlayer handles almost everything for you.

Re: Android’s 10 Millisecond Problem explained

#155
post #132

Earlier quoted context omitted.

When recording guitar on my computer, I can feel the difference between 10ms and 5ms. 10 isn't horrible, but it's definitely not optimal.

If you think about it, speed of sound is about 340.29 meters per second... also 0.34029 meters per millisecond... also 1.11644 feet per millisecond. So 5ms vs 10ms latency is like the difference between having your amp 5 feet or 10 feet away.

Worse, if the latency shifts, you start getting phase problems.

Re: Android’s 10 Millisecond Problem explained

#156
post #104

There is something I don't understand; maybe someone here can explain: Sound travels at about 340 m/s (in a typical room). That means it travels about 3.4 metres in 10 milliseconds. Therefore another way to get a 10 millisecond problem is to stand 3.4 metres from the orchestra. Most people sit farther than 3.4 metres from the orchestra, yet they don't complain about a lag between when the violin bow moves and the sou…

The audience doesn't need instant feedback and low latency, the performers do. If you listen to a classic rock album, you're hearing the sounds with a "latency" decades after they've been played. But the playing is cohesive and tight. If one of the guitarists was consistently 50ms off, you would notice it. > Most Android apps have more than 100 ms of audio output latency, and more than 200 ms of round-trip (audio inp…

> If one of the guitarists was consistently 50ms off, you would notice it.

The best movie about this, ever: https://youtu.be/VnuImW1dWAk

Re: Android’s 10 Millisecond Problem explained

#157

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

That whole theory is blown by the fact that CoreAudio supports 3rd party audio hardware. There is a thriving market of soundcards and audio peripherals for the professional Mac OS X market. Those all run CoreAudio, which is exactly what iOS runs.

Re: Android’s 10 Millisecond Problem explained

#158
post #121

Earlier quoted context omitted.

Huh, those tests show it has 35-50, not 200ms O.o

I am too lazy to try to find the exact numbers and versions but back in the Android 1.x, 2.x days, the latency was in the 200 ms ballpark. So things have improved a lot since then (even though there is still a lot of ground to cover)

https://source.android.com/devices/audio/latency_measurement...

Re: Android’s 10 Millisecond Problem explained

#160

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

This is not a good analogy. McDonald's and Ruth's Chris are not direct competitors, they are targeting completely different markets. Android and iOS are in direct competition. If we have to use a food analogy, I would propose Starbucks and a competing coffee shop. Almost all the major players in app development make corresponding Android and iOS versions of their apps. Imagine if Twitter or Snapchat only had an iOS o…

> This is not a good analogy. McDonald's and Ruth's Chris are not direct competitors, they are targeting completely different markets.

So it was good, because that was my point.

> Android and iOS are in direct competition.

Citation needed. ;-) But seriously, I don't think they are. Too many observable differences in goals and strategies across each platform for your assertion to be true.

> There is no reason to think that somehow Android users are in such a different market that they would have no interest in these apps...

On the contrary, there is every reason to think that. Outside a very narrow and limited class of tech geeks who argue on technical merits, the broader market stats point to these being very different segments with different consumer profiles valuing different things.

Post reply on HN