Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on Android's audio latency

android-developers.googleblog.com

Post reply on HN
Print view View original

151–160 of 171 posts

Re: An update on Android's audio latency

#151

Post by exikyut »

mellosouls wrote: post #102
exikyut wrote: post #88

Earlier quoted context omitted.

That sounds involved but 100% doable using synthesized volume limiting in-app. Have you tried pestering Audible? Would probably take a while, but it feels like the kind of thing that would be hard to "un-justify" once you started arguing for it.

That's a nice idea - there are apps that purport (unsuccessfully in my experience) to work around the issue using software though I don't know they use that approach. Obviously any major app supplier may be reductant to invest significant dev time to offer a workaround for an OS limitation (and Audible is just an example), but yes it's worth raising I suppose, thanks.

I had a quick poke around to see if it's possible to implement something like audio filtering on Android, and found just about exactly that question asked over at https://stackoverflow.com/questions/15385797/hook-simple-aud...; TL;DR no, for obvious (albeit annoying) security reasons.

I'm not even sure if it would be straightforward with a rooted device either.

Re: An update on Android's audio latency

#152

Post by Judgmentality »

im3w1l wrote: post #150
Judgmentality wrote: post #100

Earlier quoted context omitted.

Features require maintenance the same as products. If this feature is enough to go after entire new categories of customers, aka musicians, this feature effectively defines a new product opportunity for Google. Also Android is already buggy as fuck, so every new feature they add actually is a big deal. Ever since Google killed Reader I have no faith in them to ever maintain anything that isn't directly selling ads.

If they achieve a low audio latency, how much headcount do you think is needed to keep it low? A small fraction of an engineer, I suspect.

This is the reason I don't trust Google. What was the headcount to maintain Google Reader? I'm pretty sure an intern could do it part-time.

Also if it's part of Android, I bet it will unravel a bunch of hidden bugs that haven't been exposed before. Like I said, Android is already buggy as fuck. My Pixel 4a freezes/crashes regularly and Google told me (paraphrasing) "it just does that."

Re: An update on Android's audio latency

#153

Post by philsnow »

Godel_unicode wrote: post #66
philsnow wrote: post #63

Earlier quoted context omitted.

The article and all the responses here express "latency" as a simple scalar number. Is it actually more like a histogram of values than a scalar, and the marketing number is the 90th %ile of that histogram? My impression is that Android has more latency variance than iOS. If that's true then it's important to be clear what the reported numbers represent.

Latency variance is known as jitter. What gives you the impression that it would be high on Android?

Having used nearly every flagship android device from the HTC Dream up through the Nexus 6p, and then switching to an iphone 6 and never looking back, except watching acquaintances use their android phones.

Also from talking to an engineer who worked on earlier generations of iphones, who said that every team had a latency budget that they could not exceed.

Re: An update on Android's audio latency

#154

Post by im3w1l »

Judgmentality wrote: post #152
im3w1l wrote: post #150

Earlier quoted context omitted.

If they achieve a low audio latency, how much headcount do you think is needed to keep it low? A small fraction of an engineer, I suspect.

This is the reason I don't trust Google. What was the headcount to maintain Google Reader? I'm pretty sure an intern could do it part-time. Also if it's part of Android, I bet it will unravel a bunch of hidden bugs that haven't been exposed before. Like I said, Android is already buggy as fuck. My Pixel 4a freezes/crashes regularly and Google told me (paraphrasing) "it just does that."

Well first you need a couple of UI people to move the buttons around every once in a while to keep people on their toes. Then you need a few people keeping the backend up with deprecations, a qa person, a few people making sure porn doesn't get into Trends, and a few SRE people to make sure the servers aren't going up in flames.

Re: An update on Android's audio latency

#155

Post by fomine3 »

thefourthchime wrote: post #65
Robotbeat wrote: post #45

Responsiveness and low input-to-result latency was why I chose iPhone over android 10 years ago even though I prefer a more open environment like android. Sounds like things haven’t changed a whole lot on that front. Sometimes I wonder if these increased levels of abstraction and even digitization itself (or at least the Internet-ization of things) is a mistake for human-machine interface. Watching drone racing pilot…

What's funny is that this “open” environment of android now is nearly the opposite. With any android device openly spying on you while locking down all the open source apps you might want to install.

It never became worse than iOS on "open" perspective.

Re: An update on Android's audio latency

#156

Post by fomine3 »

morsch wrote: post #113
Jeff_Brown wrote: post #10

The figure of most interest to someone playing an electronic instrument is "tap-to-touch latency". The article indicates a minimum of 43 ms for that (28 round trip latency - 5 audio input latency + 20 touch latency). That's like ten times what you'd hope for.

The 20 ms tap-to-touch reference is from 2017, maybe this has gotten better in the past 4 years? But maybe not. And per the source, it's possible to get down to 10 ms round trip latency if you buy the right phone.

60Hz touch scan rate (16.67ms) was common in 2017, but now we can easily buy a phone with 240Hz(4.17ms) touch scan rate. It should be much improvement.

Re: An update on Android's audio latency

#157

Post by fomine3 »

AdmiralAsshat wrote: post #18

Too little, too late, I'm afraid. The improvement is great, but I think the audio professionals jumped ship long ago to Apple, and they're not going back. I know of several music professionals plugging into their Macbooks or iPads as part of the pre-amp, but I don't know if any using Android. Google sat on this for way too long while Apple courted the creative professionals, and for any that have already made the upf…

The big problem is there are few great Android tablets (mostly from Samsung, previously Huawei), and small community to buy them. It's also make less apps released for Android tablets. I prefer Android but I choose iPad because of this situation.

Re: An update on Android's audio latency

#158

Post by kall »

tekstar wrote: post #87
kall wrote: post #58

Earlier quoted context omitted.

Yeah, I think the numbers in the article should be good enough for a bunch of music use cases, but remember it used to be like half a second which is obviously unworkable. Well financed developers like ROLI already have instruments on android. I think the incredible instruments available on iOS are also there because the App Store promise actually kind of works for them. They write a great application, upload it to s…

I released free AUv3 ports of mutable instruments modules, turned into instruments. Look up Spectrum Synthesizer Bundle on App Store.

These are excellent! And you also made synthmodes which I use all the time. Thank you!

Re: An update on Android's audio latency

#159

Post by donturner »

lloeki wrote: post #133
bumbada wrote: post #128

Earlier quoted context omitted.

Input in NES is not lag's source. Input is only read once per frame. Today it is very simple and cheap to improve over old controllers. Lag comes from video. If you do not use FPGA emulators like Mister the video delay is enormous. I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV).…

> Input in NES is not lag's source. Input is only read once per frame. That’s exactly what I said ;) By virtue of being a different platform, emulation introduces a lag that is just not present on the real hardware (and can’t be lower by virtue of literally being a wire to memory). USB alone often introduces an astoundingly high minimal floor on latency. > I don't understand what you are calling 10ms lag. Have you me…

> the human brain is severely impacted by lag

The brain can compensate for lag/latency up to a point. Church organ players often have to deal with >100ms of delay between pressing a key and hearing the note produced through those big pipes.

If you have an app which produces a sound when you tap on the screen, and there's a delay of say 70ms between tapping and sound being produced, it's easily possible to play in time with an external clock source, like a metronome, as long as the delay is fixed.

In the 1968 paper "Response time in man-computer conversational transactions" actions which occurred within 100ms the human input were perceived as instantaneous. In my experience this holds true with musical instrument apps, although one must first learn how much latency is present in order to compensate for it when synchronising with other clock sources.

Post reply on HN