Android’s 10 Millisecond Problem explained • Hacker News Board

Re: Android’s 10 Millisecond Problem explained

#221

Post by darkmighty » Thu, Apr 16, 2015, 9:41 PM UTC

jblow wrote: post #152

cnvogel wrote: post #147

Earlier quoted context omitted.

Well... it's like all audio chipsets work nowadays. Only some DSPs will be able to efficiently handle single-frame data processing, but they have the help of dedicated address generators and lightweight interrupts synchronized to the digital interface. If you write "process however much audio data is ready", then you already imply that your CPU will not be up to speed to process 48000 interrupts/second reliably and y…

As someone who has actually done a good amount of soft-real-time audio programming, I can tell that you probably haven't. Everything you are saying about CPU speeds is made-up nonsense. Look into how these things are done on systems where folks actually care about latency (for example, commercial audio hardware, game consoles, etc).

Doesn't a lot of audio processing rely on FFTs, for which you need large block sizes? I agree that constantly varying fractional block sizes don't seem like a good idea.

Re: Android’s 10 Millisecond Problem explained

#222

Post by oldmanjay » Thu, Apr 16, 2015, 9:47 PM UTC

nness wrote: post #20

Can someone explain in layman's what the issue actually is, because the article, neither its comments here or on Reddit, seem to dumb it down for non audiophiles?

Audiophiles are a group of people who believe that they have magical hearing powers that are enhanced with oxygen-depleted gold cables and the scratch/hiss/pop of vinyl. This is targeted at musicians.

Re: Android’s 10 Millisecond Problem explained

#223

Post by faragon » Thu, Apr 16, 2015, 9:48 PM UTC

Android has many problems: - Poor event handling. - Braindead UI. - Braindead VM approach: WTF JIT on mobile devices??!!!

Google: fuck fix the UI, fuck fix the VM bullshit, fuck fix bloating everywhere. NDK is not the solution: the problem is in the architecture.

Re: Android’s 10 Millisecond Problem explained

#224

Post by darkmighty » Thu, Apr 16, 2015, 9:57 PM UTC

psychometry wrote: post #168

bentcorner wrote: post #145

Earlier quoted context omitted.

Sort of like why audience clapping tends to get really messy until the performer does the "hands above the head" thing to get them back in sync.

Audiences have a natural tendency to slow down. They're mostly not musicians and I imagine their clapping as a response to the music (and the other clappers) rather than internalizing the music as a performer would.

If you start from a perfectly synchronized audience and assume they clap reactively, you'd expect them to delay each of their claps by ~1/2 speed of sound * width of the room. A good example for why on music you need a good rhythm (internal constant frequency driver) instead of acting reactively to perform well.

Re: Android’s 10 Millisecond Problem explained

#225

Post by drewcrawford » Thu, Apr 16, 2015, 10:00 PM UTC

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.

So I've got a few decades of serious music training under my belt. Multi-instrument.

I notice any latency above 7ms. I can compensate pretty well between about 7-14ms. Anything above that will affect the performance. Once you get to, say, 25ms, it's like I lose several years of training.

It's hard to relate to because most people don't have experience doing tasks demanding that level of precision. Perhaps it would be useful to think about what would happen if you introduced a delay between striking a key on your keyboard and the sensation of feeling it travel. You "can type" without any sensation at all (see iPads) but people who are serious about typing go to extraordinary lengths to make the keyboard feel right.

Re: Android’s 10 Millisecond Problem explained

#226

Post by navaati » Thu, Apr 16, 2015, 10:12 PM UTC

falcor84 wrote: post #146

bentcorner wrote: post #145

Earlier quoted context omitted.

Sort of like why audience clapping tends to get really messy until the performer does the "hands above the head" thing to get them back in sync.

Clapping synchronisation is actually a well studied spontaneous occurrence, that just takes O(1) periods, see this article for some analysis: http://arxiv.org/pdf/cond-mat/0006423v1.pdf

He's talking about clapping in rythm during the music, not applause afterward (fun pdf tho)

Re: Android’s 10 Millisecond Problem explained

#227

Post by ElijahLynn » Thu, Apr 16, 2015, 11:01 PM UTC

ianlevesque wrote: post #183

daddykotex wrote: post #137

Earlier quoted context omitted.

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?

With Android the variety of customized android builds on various manufacturers does make this more challenging than it needs to be. As the article points out, many vendors simply break realtime audio by using slow drivers and slow paths. However, as someone who has dealt with Android, iOS, Windows Phone, and BB audio APIs, Android's audio API really is just amateur hour compared to Apple's, even to the present day. I…

Do you think Ubuntu for Phones (or whatever it's called) will suffer from this too? Since Ubuntu is using a portion of Android.

Re: Android’s 10 Millisecond Problem explained

#228

Post by gone35 » Thu, Apr 16, 2015, 11:04 PM UTC

kabdib wrote: post #120

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

"A little manly-man programming from the wrist and we move on to real problems."

See... it's the little things like this. I am pretty sure that was not your intention, but please do know that turns of phrases like that hurt a little, and exclude a little.

To see what I mean, s/man/jew/ or s/man/white/ or some other category and see how it reads.

Re: Android’s 10 Millisecond Problem explained

#229

Post by DigitalSea » Thu, Apr 16, 2015, 11:27 PM UTC

This is the one downside with using Android I have experienced. I came from an iPhone 4 and as an amateur musician I used it to produce music, record ideas on the go and whatnot. When I moved to a Samsung Galaxy S4 (my first Android phone) I was mortified. I grown to love a couple of drumming applications on iOS, when I moved to Android there were a few sub-par applications and they all had ridiculous latency, to the point they were not usable and I had to bust out my keyboard at home to record drums (no drum ideas on the go anymore). You hit a snare in a drumming app and it felt like hundreds of milliseconds of lag, horrible.

It was so bad to the point where I went out and purchased an iPad just so I could have that freedom of recording ideas when I am not at home. The iPad and iPhone offered what sounded like basically no latency at all, I never understood why Android devices struggled (but I speculated and assumed it was how the audio was being processed). I considered moving back to an iPhone, but I love the freedom that Android affords me and the competition, so I stuck it out and kept using the iPad.

I recently purchased a Samsung Galaxy S6 Edge and while I still notice some slight latency, it is usable again. I can finally jot down ideas when I am away from home using my phone again. Research seems to yield some improvements that Samsung themselves have made to their hardware and software, not to mention the professional audio driver that allows the use of a third party audio interface (great feature by the way). Google needs to make this a priority, because believe it or not a lot of people use their tablets and phones to produce music. We need to fix this.

Music production might not seem like a big deal to Google, but Apple definitely gets it and have from the beginning. The one aspect I miss about owning an Apple device, not enough to make me switch back but definitely a good feature of iOS devices.

Re: Android’s 10 Millisecond Problem explained

#230

Post by [deleted] » Thu, Apr 16, 2015, 11:41 PM UTC

ElijahLynn wrote: post #227

ianlevesque wrote: post #183

Earlier quoted context omitted.

With Android the variety of customized android builds on various manufacturers does make this more challenging than it needs to be. As the article points out, many vendors simply break realtime audio by using slow drivers and slow paths. However, as someone who has dealt with Android, iOS, Windows Phone, and BB audio APIs, Android's audio API really is just amateur hour compared to Apple's, even to the present day. I…

Do you think Ubuntu for Phones (or whatever it's called) will suffer from this too? Since Ubuntu is using a portion of Android.

[deleted]