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

81–90 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#81

Post by abruzzi »

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 (techno/EDM) and less with a slow jazz ballad.

Re: Android’s 10 Millisecond Problem explained

#83

Post by masklinn »

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.

The title isn't clear but (sub-) 10ms is the target.

The "problem" part is that Android devices generally don't come close, the lowest-latency Android device on the market today (barring Samsung's custom "Professional Audio SDK") has a 35ms roundtrip latency (ADC -> DAC), and many devices are way beyond 100ms (http://superpowered.com/latency/)

Re: Android’s 10 Millisecond Problem explained

#87

Post by hrnnnnnn »

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.

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.

Re: Android’s 10 Millisecond Problem explained

#88

Post by CountSessine »

nsajko wrote: post #79

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

Given that each sample means a kernel mode-user mode trip and various context switches, I'm going to guess that halving the sample size globally would make your phone's audio handling consume more CPU.

Re: Android’s 10 Millisecond Problem explained

#89

Post by worklogin »

csixty4 wrote: post #71
megaman22 wrote: post #35

Earlier quoted context omitted.

Nor do most people who do live in the US, I would imagine... I infer that it's a high-end steak joint, but I've never heard of it.

I haven't heard that name since leaving the Midwest.

They have locations in DC, San Francisco and South Texas, so they're around.

Re: Android’s 10 Millisecond Problem explained

#90

Post by SigmundA »

TorKlingberg wrote: post #62
amelius wrote: 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.

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 to give ease of use, sometimes at the cost of performance and flexibility.

Post reply on HN