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

231–240 of 311 posts

Re: Android’s 10 Millisecond Problem explained

#231

Post by engi_nerd »

gone35 wrote: post #228
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.

I did the substitution in my head and the statement sounds silly. Just like "manly-man" sounds silly.

Is this genuinely offensive and exclusive though?

Re: Android’s 10 Millisecond Problem explained

#232

Post by ianlevesque »

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.

I'm not that familiar with Ubuntu Phone, but from a look at the docs I am concerned that it may have some of the same media issues (or at least the same variations between vendors). According to the architectural overview in the porting guide[1] their Qt-based API sits on top of some abstractions of their own, which then sit on top of stagefright, OMX, and Android's HAL (and thus Android's drivers). Not reassuring.

I'd personally be much more at ease if I saw ALSA sitting directly under Qt, but I can understand why they'd want to leverage the huge Android hardware ecosystem.

1. https://developer.ubuntu.com/en/start/ubuntu-for-devices/por...

Re: Android’s 10 Millisecond Problem explained

#233

Post by rcr »

gone35 wrote: post #228
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.

You can't really be serious.

Re: Android’s 10 Millisecond Problem explained

#234

Post by AaronIG »

gone35 wrote: post #228
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.

The phrase he used has a fairly well understood meaning, so of course the substitution would read differently. It would be an entirely new phrase. Different words/phrases have different connotations.

Re: Android’s 10 Millisecond Problem explained

#235

Post by UberMouse »

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?

The website font? I'm viewing it on a 27" 2560x1440 screen, Chrome 42 and OS X 10.10 and the fonts are normal sized for me. In fact larger than the HN font.

Re: Android’s 10 Millisecond Problem explained

#236

Post by nitrogen »

cnvogel wrote: post #184
jblow wrote: post #179

Earlier quoted context omitted.

I am not sure we can make the assumption that the input and output devices are on the same clocks or run at the same rates. Maybe they are (in a good system you'd hope they would be), but I can think of a lot of cases where that wouldn't be true. However, even when they are synced, you can still easily see the problem. The software is never going to be able to do its job in zero time, so we always take a delay of at…

Music or video production studios typically have a central clock, so for this use-case the sample rates should be perfect. But even if the input and output devices are on perfect clocks, with NTSC (59.94 Hz), you'd need a very odd number of samples per video frame in your software, if your processing would happen at a integer fraction of the video frame rate.

Do you know whether studios use 48000Hz with 59.94fps or 48000/1.001 ≈ 47952Hz? Does converting from 24fps film to 23.976fps Blu-ray require resampling the audio? Or are films recoded at 48048Hz and then slowed to 48000 for consumer release?

Re: Android’s 10 Millisecond Problem explained

#237

Post by shaftoe »

gone35 wrote: post #228
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.

I don't get it.

I read his comment as self-deprecating humor. If he had used white, jew, or whatever else may apply, it would still be self-deprecating humor, which is generally non-offensive for the simple reason it applies to the self.

Re: Android’s 10 Millisecond Problem explained

#238

Post by general_failure »

gone35 wrote: post #228
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.

This comment is terrifying. You cannot say anything without being called out with this sort of terrible attitude.

Re: Android’s 10 Millisecond Problem explained

#239

Post by smadge »

gone35 wrote: post #228
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.

"phrases like that hurt a little, and exclude a little."

I agree with you on that part but your substitution doesn't make much sense.

The original comment links programming competency to masculinity, which is a problem. It's as simple as that.

Re: Android’s 10 Millisecond Problem explained

#240

Post by macintux »

towelguy wrote: post #163

It's interesting that their business bases on Google not fixing this problem. What happens when they fix it?

People have been assuming Apple's success depends on one or two minor features that someone else will copy and destroy their business for, well, ever.
Post reply on HN