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

121–130 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#121

Post by izacus »

Synaesthesia wrote: post #113
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.

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

Re: Android’s 10 Millisecond Problem explained

#122

Post by marcosdumay »

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

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 of the application you want low latency from - but here I'm talking about 1ms latency).

Anyway when using a cheap USB interface, I'd focus on improving the hardware first. Low latency and high throughput USB isn't cheap (nor is it available at every computer).

Re: Android’s 10 Millisecond Problem explained

#123

Post by digi_owl »

rglullis wrote: post #117
digi_owl wrote: post #76

Earlier quoted context omitted.

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

Well at least having Skype go Pulseaudio only prompted the creation of https://github.com/i-rinat/apulse.

Re: Android’s 10 Millisecond Problem explained

#124

Post by sundarurfriend »

izacus wrote: post #121
Synaesthesia wrote: post #113

Earlier quoted context omitted.

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.

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

They also mention that those tests were made in the best case scenario (disabling noise correction, etc. for the sake of speed) with the best performing mobile, and by following Google's low latency guidelines. Most Android apps don't have the first two luxuries in the general case, and (apparently) don't bother with the last one, thus the much higher latencies in practice.

Re: Android’s 10 Millisecond Problem explained

#125

Post by BFay »

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…

Pulseaudio has gotten a really bad rep, and I think there was at time where it was legitimately awful, but I think it's better than it was.

On mainstream distros with pulseaudio like Fedora or Ubuntu, audio just works, when you don't have low-latency requirements.

When you do have low-latency requirements, things are a bit tricky. You do pretty much need to get a low-latency or realtime kernel, and you definitely want to use Jack or ALSA. Maybe this setup is a little more frustrating than Windows, where you may just need to install one driver like ASIO4ALL.

But it's flexible, and you can actually get Pulseaudio and Jack working pretty well together after installing the pulseaudio-module-jack. You can turn on jack when you need it, turn it off when you don't, and all of the pulseaudio stuff will get routed through it so that you don't lose sound from your other applications. If you want, you can route audio from pulseaudio into whatever other audio applications you're using - sometimes I like taking Youtube videos and routing the audio through weird effects in Pure Data.

I toggle jack on and off with this little script, works pretty well for me right now: https://gist.github.com/YottaSecond/f0a1b515f95b2e791755

Re: Android’s 10 Millisecond Problem explained

#126

Post by nileshtrivedi »

ynniv wrote: post #49

TL;DR the Linux layer (ALSA) and the Java layer (Audio Flinger) use widely compatible but high latency techniques, whereas Apple designed their API's and hardware such that these layers can be optimized to almost nothing. (From the article: http://superpowered.com/wp-content/uploads/2015/04/Android-A... )

ALSA with JACK has been shown to give latencies less than 2ms.

Re: Android’s 10 Millisecond Problem explained

#128

Post by krakensden »

guelo wrote: post #38

Up to the ALSA driver step these delays would be the same on any Linux system. Do Linux desktop systems experience these types of delays? I have experienced these types of delays trying to setup a Windows box as karaoke machine. In fact, I've never seen a DJ use anything but a Mac. That leaves the question, how does Apple do it?

ALSA isn't the problem- JACK runs on top of ALSA, and people comfortably run well under 10ms. The problem is higher up in the stack. Even switching to the much-maligned pulseaudio could be a huge improvement: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-f...

Re: Android’s 10 Millisecond Problem explained

#129

Post by mox1 »

I spent a lot of hours fighting with the low level Android libraries while writing a Spotify App for Android back in late 2013. There is very little documentation on the web (especially for streaming Audio). Getting this working was a serious headache.

If anyone is interested, I pulled the OpenSL ES parts out and posted them to github.

https://gist.github.com/mox1/3516112bc52c54aabb98

Re: Android’s 10 Millisecond Problem explained

#130

Post by CamperBob2 »

nsajko wrote: post #79

What downsides would there be to just halving the period size?

The heart of the problem is simply the limited timing and computational resources in a multitasking non-realtime OS.

The smaller the audio buffers are, the more prone they'll be to starvation. Only if the application can be guaranteed to receive interrupt service and/or thread timeslices at a 100 Hz rate or better is it possible to achieve audio latency of 10 milliseconds. That's a difficult thing to guarantee in a modern consumer OS. It can be done, but it won't happen by accident, only by design.

The penalty for failing to service your 10-ms buffer is a dropout that sounds much worse than slightly higher latency, so there's an incentive to use larger buffers than necessary at every link in the signal chain. From the point of view of the OS vendor, musicians might complain about latency, but everyone will complain about dropouts.

Post reply on HN