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

111–120 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#111

Post by JonFish85 »

troymc wrote: 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…

Probably because in this orchestra example the feedback is purely passive (you didn't take any action), whereas with Android the delays are after an action you took, so it's psychologically jarring (seeing the response to your action immediately, and hearing the response roughly 10ms later). Just my guess.

Re: Android’s 10 Millisecond Problem explained

#113

Post by Synaesthesia »

troymc wrote: 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…

I'm a musician, 10ms latency would be fine, however as they note, most Android apps have 100ms latency, or 200ms round-trip latency. That is definitely not usable.

Re: Android’s 10 Millisecond Problem explained

#114

Post by marcosdumay »

troymc wrote: 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…

Android' problem is that it has a 100-200 ms lag. The stated 10 ms is the goal.

Also, most people don't notice the lag between the instruments of an orchestra because the instruments are close to each other. Their distance to the listener is not relevant.

Re: Android’s 10 Millisecond Problem explained

#115

Post by TorKlingberg »

SigmundA wrote: post #90
TorKlingberg wrote: post #62

Earlier quoted context omitted.

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.

In your ALSA example the lower level API doesn't prevent you from mixing audio, it simply isn't as easy because you must implement it yourself, this could be arguably more flexible as well. Abstractions can hide features of the hardware but they cannot create new hardware. Whatever the abstraction is doing the client software could do instead with the lower level API. So I would say abstraction layers are often added…

I think this whole subthread is about different meanings of "flexibility".

An audio abstraction layer can allow different kinds of audio hardware without changing the apps, which is a kind of flexibility.

Re: Android’s 10 Millisecond Problem explained

#116

Post by Synaesthesia »

abruzzi wrote: post #81
ohitsdom wrote: post #73

Is 10ms really that big of a deal? I'm an amateur musician so have some experience playing in bands, but I have a hard time believing 10ms would feel off when playing with others.

I think the biggest problem is that 10ms is more than enough to throw off a performer because it feels like a lag between when you hit the key and the note sounds. This makes it hard to play proficiently for anything with a fast tempo because it feels like the sound engine isn't keeping up with you. For an audience, 10ms is going to feel like sloppy timing. That will be more of an issue with tightly timed music (tech…

Really 10ms is ok, and you can cmompensate for it mentally. As they note, it's because Android music apps actually have a latency of 100ms or worse - that it's a problem.

Re: Android’s 10 Millisecond Problem explained

#117

Post by rglullis »

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…

Yeah, I mentioned aRTs but I was actually thinking of Jack (too late to change it). The annoying thing with these different sound systems is that it turns a general purpose workstation into an either/or proposition.

- The applications that depend on pulseaudio were really not happy when jack was the sink.

- Skype wouldn't work.

- Because of the real-time requirements of the sound applications, everything else felt absolutely sluggish.

- The volume control stopped working.

All in all, I'd have to setup a separate system just to run jack-dependent applications.

Re: Android’s 10 Millisecond Problem explained

#118

Post by copx »

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.

Windows overcame its audio latency issues in the Vista days by introducing WASAPI (Windows Audio Session API), an API especially designed for professional audio processing.

It grands an application exclusive, direct control of the audio hardware drivers, bypassing the higher-level audio layer of the OS.

That + real-time threads (I do not know how old that feature is) allows for pro-grade latencies.

Re: Android’s 10 Millisecond Problem explained

#119

Post by iamshs »

troymc wrote: 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…

Maybe because 10 ms delay is not perceived by our eyes. Eye does not have slow motion capabilities to be able to capture that small of frame rates.

Re: Android’s 10 Millisecond Problem explained

#120

Post by kabdib »

I'd heard over the years that working with isochronous systems was difficult. I'd done a number of real-time systems before, and written OS schedulers and NTP-like systems and so forth. A little audio work should be a walk in the park, right? A little manly-man programming from the wrist and we move on to real problems. So I walked into an audio project thinking that "Oh, this latency and synchronization stuff, how bad could it really be?"

Bad.

Nailing down buffer-bloat and sources of latency and jitter in an isochronous system took several months, the last few weeks of which were 80-100 hour weeks just before ship. Several times we thought we'd fixed the issues, only to find that our tests had been inadequate, or that some new component broke what we had built.

I remember nearly being in tears when I finally realized what the clock root of the audio system actually was, and that it wasn't what people had been using. From there everything fell into place.

Don't pull the number of buffers you have out of thin air ("Oh, six is enough, maybe twelve, don't want to run out in my layer of the system, after all...") Don't assume your local underflow or overflow recovery strategy actually works in the whole system. Don't assume your underlying "real time" hypervisor won't screw you by halting the whole god damned system for 20ms while it mucks around with TLBs and physical pages and then resumes you saying, "Have fun putting all the pieces of your pipeline back together, toodle-oo!" Put debug taps and light-weight logging everywhere and attach them to tests. And know what your clock root is, or you will be sunk without a trace.

Isoch is hard.

Post reply on HN