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

211–220 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#211

Post by JoeAltmaier »

lostgame wrote: post #210
JoeAltmaier wrote: post #199

Earlier quoted context omitted.

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.

Did you not get the '5 year head start' bit? Doesn't matter how fast developers create applications that are amazing, iOS has already had all these years to create an already fantastic subset of these applications. Doesn't matter how 'good' it looks - for the use case of music, android has simply lost.

That was actually my point. There's no need for Android development to cover that ground - it can just start where we are now, with cool apps that can just be ported over. Once the Android audio latency issue is addressed.

App developers LOVE to port, its another sale with small effort.

Re: Android’s 10 Millisecond Problem explained

#212

Post by cfstras »

Going completely off-topic: Why has everyone recently decided to use ultra-thin fonts everywhere? On my system (24" FullHD, Win8.1, Chrome 42 and Ubuntu 14.04, Chrome 43) the text is thinner than one pixel and thus unreadable below 130% zoom. Sure, I can open up DevTools and fix the font-weight, but seriously?

Re: Android’s 10 Millisecond Problem explained

#214

Post by emn13 »

cfstras wrote: post #212

Going completely off-topic: Why has everyone recently decided to use ultra-thin fonts everywhere? On my system (24" FullHD, Win8.1, Chrome 42 and Ubuntu 14.04, Chrome 43) the text is thinner than one pixel and thus unreadable below 130% zoom. Sure, I can open up DevTools and fix the font-weight, but seriously?

My theory on this is that Windows 8 hyped this.

It's particularly problematic when it's being copied in mac circles because OSX has a biased font-smoothing algorithm that adds font weight (it's a design flaw). In other words, to get something to look thin on a mac, especially a non-retina mac, it needs to be very thin, sometimes less than a pixel thin. How other systems display borderline visible strokes varies depending on the system and the details of the font.

Re: Android’s 10 Millisecond Problem explained

#215

Post by jblow »

FigBug wrote: post #177
jblow wrote: post #165

Earlier quoted context omitted.

I could type up a thorough explanation, but it would take about an hour, and I have a lot to do. It is actually not a bad idea to do such a write-up, but I don't think the appropriate venue for it is an ephemeral post on Hacker News ... I'd rather blog it somewhere that's more suitable for long-term reference. But I'll drop a few hints. First of all, nobody is talking about running interrupts at 48kHz. That is comple…

> Since the one coming from the hardware is completely fictitious Why do you say this? The USB audio card (or similar) is generating blocks of audio at a fixed rate, no? Maybe for video playback or games you need to synchronize audio and video, but there is no need to do that for music production apps. If you are writing some sort of synth, as soon as you receive a midi note or a tap, trigger the synth and the note w…

Well, it depends on how that specific hardware is designed, but we could say that hardware that is designed to generate only fixed blocks of audio is very poor from a latency perspective.

I think you will find, though, that most hardware isn't this way, and to the extent this problem exists, it is usually an API or driver model problem.

If you're talking about a sound card for a PC, probably it is filling a ring buffer and it's the operating system (or application)'s job to DMA the samples before the ring buffer fills up, but how many samples is dependent upon when you do the transfer. But the hardware side of things is not something I know much about.

> If you are writing some sort of synth, as soon as you receive a midi note or a tap, trigger the synth and the note will play in the next audio block

Yeah, and waiting for "the next audio block" to start is additional latency that you shouldn't have to suffer.

> If you are doing some sort of effect, grab the input data, process and have it ready for the next block out. I don't understand why you need a second loop.

The block of audio data you are postulating is the result of one of the loops: the loop in the audio driver that fills the block and then issues the block to user level when the block is full. My whole point is you almost never want to do it that way.

Re: Android’s 10 Millisecond Problem explained

#216

Post by madez »

vlaskovits wrote: post #64

Hi everyone -- Gabor and I wrote the piece -- let us know if you have any questions we can help answer for you.

What are the concrete steps you are taking to tackle the issue?

Idea: A latency ranking for devices would put pressure on manufactures.

Will you work together with the Linux community so we all benefit from it?

Re: Android’s 10 Millisecond Problem explained

#217

Post by jblow »

fl0wenol wrote: post #191
jblow wrote: 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"?

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

Why is (2) dependent on anything regarding the number of samples you get at once? Sure, suppose there is a maximum block size; why does anything regarding copying "an entire something" require you to have filled that entire block size with live data? Why can't you just copy however much is available in the buffer?

I don't understand why copies are even relevant: you can make several extra copies and nobody will ever notice. Audio data is trivial in modern systems. Let's say there are two channels coming in; 48000 * 2 * 2 bytes per second is an absolutely trivial amount of data to copy and has been for many years. Building some convoluted (and unreliable) system just to prevent one copy per application, when each application is going to be doing a lot of nontrivial processing on that data, strikes me as foolish. But don't listen to me, look at the fact that Linux audio is still famously unreliable. If the way it's done were a good idea, it would actually work and everyone would be happy with it.

Re: Android’s 10 Millisecond Problem explained

#218

Post by Polyphonie »

One of the reason for the audio latency issue on Android is the complex power management circuitry (PMIC) implemented on most of not all Qualcomm SoCs. That's why to anyone with experience in regards to using Android device in audios production, most would agree that the older 2011 Galaxy Nexus is still the Android device to use. Unlike the the recent Snapdragon based Nexus device, the GNex is based on TI OMAP4460 (dual-core ARM Cortex A9). It might not be a coincidence the Apple kept the number of cores on its A series SoCs to a minimum (only moving to 3 with the A8X).

http://createdigitalmusic.com/2013/05/why-mobile-low-latency...

Re: Android’s 10 Millisecond Problem explained

#219

Post by wrl »

jblow wrote: post #165
cnvogel wrote: post #153

Earlier quoted context omitted.

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

I could type up a thorough explanation, but it would take about an hour, and I have a lot to do. It is actually not a bad idea to do such a write-up, but I don't think the appropriate venue for it is an ephemeral post on Hacker News ... I'd rather blog it somewhere that's more suitable for long-term reference. But I'll drop a few hints. First of all, nobody is talking about running interrupts at 48kHz. That is comple…

> Any audio issue where the paradigm is "give the API a callback and it will get called once in a while with samples" is terrible for multiple reasons

This is, actually, how most professional audio APIs are designed and they generally work quite well. ASIO, VST, JACK, PortAudio, CoreAudio, etc.

Re: Android’s 10 Millisecond Problem explained

#220

Post by yeureka »

I am writing a game that implements an audio sequencer and it runs great on iOS and OSX. But I had to write a karaoke app for Android recently and found an amazing 100ms latency there which makes me think I won't be able to port my game to Android... Wish Google fixed this.
Post reply on HN