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

191–200 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#191

Post by fl0wenol »

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

1) Userspace sleeps until audio data is available because there's an eternity of clock cycles between each sample; do you want to be woken up after every sample if you're done doing work or a handful? You could also busy wait but that kills battery life.

2) In order to hand you off some samples you have to at least make one copy. It's convenient to be able to copy an entire _something_ without worrying about the sound card trying to DMA into it (and any hardware-specific details to make that possible).

The difference here is that with something like jackd (similar conceptually to CoreAudio or ASIO) there is just the hardware buffer in the kernel and the user buffer in jack which can be basically "shared" by all jack-enabled apps without additional copying on the user-space side. On the other hand you can't do sample-rate conversion and per-app volume control with something like that.

But if you're doing audio software you're not worrying if flash is too loud and Skype is too soft. It's a whole-system thing enabled by the software and all the buffers and latency are being managed there.

Re: Android’s 10 Millisecond Problem explained

#192

Post by blkhp19 »

daddykotex wrote: post #137
S_A_P wrote: post #43

Reading about this takes me back to the late 90s. I had just gotten serious about recording music on my computer and purchased an 866mhz dell pc. I was a using windows 98 and ASIO was still mostly a Steinberg only development and I couldn't afford cubase. I got a hand me down version of cakewalk pro audio 8. I remember the latency of that set up was about 35ms and thinking this is pretty good. There was some degree o…

Is it possible that their Audio API is much simpler due to the fact that they control all of the implementations (Hardware interface) of iOS?

Considering OS X can run on regular old Intel PCs (including the Surface 2!), I'm going to guess that they just have a rock solid, low latency solution, and not something tied to a specific platform.

Re: Android’s 10 Millisecond Problem explained

#193

Post by mSparks »

nathanb wrote: post #44
S_A_P wrote: post #43

Reading about this takes me back to the late 90s. I had just gotten serious about recording music on my computer and purchased an 866mhz dell pc. I was a using windows 98 and ASIO was still mostly a Steinberg only development and I couldn't afford cubase. I got a hand me down version of cakewalk pro audio 8. I remember the latency of that set up was about 35ms and thinking this is pretty good. There was some degree o…

Thank you, that's exactly what I was wondering. I didn't see anything in the article that gave good reasons for why iOS would be a significant improvement.

Hmm, or it could just be there are a ton of very good free audio apps for android so no interest in paying for them?

Re: Android’s 10 Millisecond Problem explained

#194

Post by astral303 »

code_duck wrote: post #142

Interesting to read of the details behind this issue. This has been a serious issue for me - it's actually why I own an iPhone. My first modern touch device was an iPod touch 4. I downloaded Garage Band and, as a long time milt instrumentalist and composer, loved it. I was amazed by how well the touch instruments worked and how easily I could record riffs and flesh out small snippets of songs. It ran almost flawlessl…

Thanks for a musician's perspective!

Re: Android’s 10 Millisecond Problem explained

#195

Post by s73v3r »

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…

Because they're sitting back and listening to the music. They're not pressing buttons and expecting feedback within a specific timeframe.

Re: Android’s 10 Millisecond Problem explained

#196

Post by stinos »

cnvogel wrote: post #140
stinos wrote: post #29

So if I get it correctly the problem is twofold: there is some extra intermediate processing and the buffer size and sampling rate are fixed to 256 samples and 48kHz respectively? And which of these two does Superpowered fix? Or both? And what would be the lowest possible latency on for example the Nexus 9?

The lowest possible input-to-output latency of an audio workstation is always two times the period size (samples/buffer) (plus a few microseconds of internal delays in the ADCs, controllers, ...) The sound chips operate on integral periods or a fixed number of samples, and when you get a period worth of audio data from your ADC, the DAC will already have started putting out the first samples of the next period. Hence…

+1 for this fine explanation. However I'm well aware of how this works and my actual question was really what part of the problem in achieving this ideal scheme Superpowered is solving. Or are they just targetting <10mSec latency? Are they getting rid of intermediate layers? Or are they just lowering buffersize? Or both?

Re: Android’s 10 Millisecond Problem explained

#197

Post by fnordfnordfnord »

shub wrote: post #135
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…

IANA neuroscientist but it seems reasonable that the brain will fix up small errors. It has to anyway, because it has its own input latency. Besides, the article is referring to discrepancies between multiple audio tracks, which don't depend on vision at all. For a real-world example, listen to 2 TVs several meters apart and tuned to the same channel. At least with OTA or cable you can expect them to be playing ~simu…

>Besides, the article is referring to discrepancies between multiple audio tracks, which don't depend on vision at all.

They do depend upon vision or touch if it is an interactive app.

>For a real-world example, listen to 2 TVs several meters apart and tuned to the same channel. At least with OTA or cable you can expect them to be playing ~simultaneously but the skew between the received signals is easily perceptible.

I believe what you're experiencing is the difference in decoding latency between different models of TV set. Several meters (3m) represents only about ~9ns (practically, low tens of ns if the cables are longer than necessary) maximum delay. It would not be directly perceptible by a person. Signal delay in a cable is ~1ns/ft.

Re: Android’s 10 Millisecond Problem explained

#198

Post by lostgame »

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 the race anymore?

Sorry, despite it's absolutely God-awful flaws such as no user-accessible filesystem, no ability to do a basic task such as download an MP3, without GarageBand (and it's awesome ability to open files I sketch out on the go right in Logic on my Mac...), without iElectribe, and the list goes on, I absolutely just can't even use the platform, and I have no reason to go back 5 years technologically.

Sorry, Android, you already lost, here is a user you can never have.

Re: Android’s 10 Millisecond Problem explained

#199

Post by JoeAltmaier »

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.

Re: Android’s 10 Millisecond Problem explained

#200

Post by ris »

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

"Isn't this kind of a known issue in Linux land?"

No. If you're doing serious audio in Linux, you use jack and get fantastic latency properties.

This is a Solved Problem.

Post reply on HN