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

121–130 of 171 posts

Re: An update on Android's audio latency

#121

Post by cout »

jancsika wrote: post #43
raphlinus wrote: post #29

Earlier quoted context omitted.

That's actually the joke here, which got a chuckle out of me. The idea is that excessively large audio latency itself has gotten cancelled. I haven't played with it myself (it's been a few years since I was actively involved in Android audio latency), but from what I've seen, AAudio is pretty good, probably close to what the hardware is capable of. I'd very much encourage people to do empirical measurements against,…

> I'd very much encourage people to do empirical measurements against, for example, PipeWire (which also looks good). A rule of thumb from reading linux audio mailing lists but which probably works generally-- completely disregard any claim of measurement of latency that isn't prefixed. For example, the Google blog labels the Y-axis with "round-trip time in milliseconds." They're clearly and explicitly measuring roun…

Are you saying there is still a use case for going straight to ALSA without something in the middle?

Re: An update on Android's audio latency

#122

Post by cout »

mellosouls wrote: post #32

Off topic, but would be nice if they could do something - presumably far simpler - about the lack of fine-grained volume control. It might be a niche case, but it's really frustrating using the various sleep-related audio apps at night with earphones and not being able to select a minimum volume that is both loud enough to hear but not so loud it keeps you awake (example: Audible with a sleep timer). I'm sure there a…

My ears have aged, but when I was younger, I was frustrated that my flip-clock/radio could not go low enough before the volume hit zero. It had an analog volume dial.

I had the impression the problem was physical limitations with the dial. With fully digital controls, it seems like this wouldn't be an issue. But obviously you need more than the handful of steps the volume buttons on the side of the phone give you.

Re: An update on Android's audio latency

#123

Post by izacus »

crazygringo wrote: post #72
com2kid wrote: post #25

It'd be nice if something was done about the extra 100-200ms (!!) of latency that Bluetooth headsets can add[1]. I understand this is largely a problem from the manufacturer problem, but I'd love to see Google lead the way with some sort of certification program, or even make their own low cost BT chipset for 3rd party headphones to use, to improve the situation. Of course Android is already world's better than deskt…

I've never understood why Wi-Fi latency is only 2-3ms while Bluetooth is 100-200ms when they use the same frequency band. Is it intentional to ensure there's plenty of buffer so audio packets can be re-sent when they fail, and the audio is seamless? In other words, is 100-200ms just inherent at that frequency with expected interference? Or is it actually just terribly designed?

> I've never understood why Wi-Fi latency is only 2-3ms while Bluetooth is 100-200ms when they use the same frequency band.

You're mixing up two different things. Transport latency of WiFi is 2-3ms, but for bluetooth you're suddently talking about a transport, codec, receive buffer and playback code latency. That's not an apple-to-apple comparison.

If you want comparable numbers, measure the latency of audio being streamed from one computer to another via PulseAudio and you'll quickly see that it's more than 2-3ms. And there's a reason for that: most people strongly prefer their music to not stutter and work properly with all kinds of headphones instead of having absolutely no latency. Most people prefer to shove their phone in a separate room, back pocket and walk around RF saturated areas and still listen to music without interruption.

Hence the manufacturers err on the side of buffering some audio so it's more resilient to connection dropouts. You wifi, after all, doesn't need to move around busy highways and public transport systems.

Re: An update on Android's audio latency

#124

Post by izacus »

com2kid wrote: post #40
kevingadd wrote: post #26

Earlier quoted context omitted.

There are low latency bluetooth protocols, if you sort by latency on rtings for aptx-LL you can see some headsets are down below 40ms. Of course, this relies on both the host and the headset having support for the protocol and being engineered well. SBC and aptX just aren't designed for low latency, and low latency is something that can't be hacked into every codec after the fact.

I'll argue that an device meant for phone calls (which is where bluetooth audio started out!) should aim for low latency by default. I also understand that the CPU/Latency/Memory trade offs made over a decade ago are not the same one's we'd make now. Doesn't change the fact that the same device can have a 3x latency difference between platforms with the same codec. Google went and developed VP9 as a royalty free code…

> I'll argue that an device meant for phone calls (which is where bluetooth audio started out!) should aim for low latency by default. I also understand that the CPU/Latency/Memory trade offs made over a decade ago are not the same one's we'd make now.

It turns out that the device that's meant for phone calls has to, first and foremost, make sure that there are no dropouts, crackles and other buffer underrun articles. Latency comes afterwards.

Re: An update on Android's audio latency

#125

Post by lloeki »

de6u99er wrote: post #73
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…

Totally agree. We should not forget that our brain is great at adjusting to latency. In the old days, when I was excessively playing Quake 3 Team Arena it took me just a couple of minutes to adjust to network latency depending on the server I was connected to. Professional musicians do this constantly and are much better at that.

What. Our brain is absolutely terrible at adjusting for latency. It can somewhat compensate, but only to an extent, and at severe cost.

There’s this video around that puts people in a VR helmet playing A/V with a delay, even the lowest setting completely destroys any form of efficiency.

Anything below 60Hz in VR has a significantly increased chance of giving motion sickness due to latency.

Playing Super Mario Bros in an emulator is strangely subtly harder than on the real NES hardware, just because of a slight lag added (can’t recal on NES but on SNES buttons literally bit-flip the RAM, hard to beat that). You can train all you want on an emulator, when you get back to the real thing it’s obvious it was just so crippling.

Try Guitar Hero / Rock Band with various audio / video latency settings. 10ms is obviously impactful, anything higher borderlines on unplayable, and even 5ms has a subtle impact increasing missing notes.

As for pro musicians, they absolutely loathe latency. This is why bassists (tempo) / drummers (rhythm) / conductors (tempo) exist: they serve as a single source of truth to sync on. In fact, we’re so sensitive to latency that the slightest deviation is unbearable, hence why following them put you back in sync. Same for effect pedals, amps, feedbacks... any latency is destroying.

Try playing on Zoom, it’s absolutely impossible (unless you assume latency is fixed, which it is not, and play in a tempo matching latency exactly, and follow the lead but time-warp your play by one beat, which I imagine is possible as a sort of canon but absolutely horrendous) unless you completely ignore the other part and find a common time source to sync upon.

Now you mention Quake 3, and it might just be you were severely misled by several critical innovations that game introduced, like network prediction and frame interpolation, negating most of the practical effects of latency.

https://www.jfedor.org/quake3/

Re: An update on Android's audio latency

#126

Post by bentpins »

kall wrote: post #51
thomasahle wrote: post #36

Earlier quoted context omitted.

What are the equivalent numbers for iPhone? Touch to audio and round-trip times?

This data [0] doesn't have the latest models, and it's meassuring latency internaly, not "touch-to-sound". The ones they tested average around 7-8ms. I've heard of Edit: I've been thinking about this and a touch-to-tone latency below 10ms seems imposible, even with the 120hz digitizer on newer iPhones. I would be very interested in seeing some experimental data as well. [0] https://juce.com/discover/stories/Mobile%20…

Xiaomi has hit 480hz touch sampling with the Mi 11. It looks possible in hardware and in software, someone just has to manage to perfect both in the same phone

Re: An update on Android's audio latency

#127

Post by indymike »

lloeki wrote: post #125
de6u99er wrote: post #73

Earlier quoted context omitted.

Totally agree. We should not forget that our brain is great at adjusting to latency. In the old days, when I was excessively playing Quake 3 Team Arena it took me just a couple of minutes to adjust to network latency depending on the server I was connected to. Professional musicians do this constantly and are much better at that.

What. Our brain is absolutely terrible at adjusting for latency. It can somewhat compensate, but only to an extent, and at severe cost. There’s this video around that puts people in a VR helmet playing A/V with a delay, even the lowest setting completely destroys any form of efficiency. Anything below 60Hz in VR has a significantly increased chance of giving motion sickness due to latency. Playing Super Mario Bros in…

Can confirm that many musicians have to play with latency. Pipe organs, heavily processed guitars (delay is an effect that is very commonly used) all are laggy and you have to play ahead of your accompaniment.

Re: An update on Android's audio latency

#128

Post by bumbada »

lloeki wrote: post #125
de6u99er wrote: post #73

Earlier quoted context omitted.

Totally agree. We should not forget that our brain is great at adjusting to latency. In the old days, when I was excessively playing Quake 3 Team Arena it took me just a couple of minutes to adjust to network latency depending on the server I was connected to. Professional musicians do this constantly and are much better at that.

What. Our brain is absolutely terrible at adjusting for latency. It can somewhat compensate, but only to an extent, and at severe cost. There’s this video around that puts people in a VR helmet playing A/V with a delay, even the lowest setting completely destroys any form of efficiency. Anything below 60Hz in VR has a significantly increased chance of giving motion sickness due to latency. Playing Super Mario Bros in…

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).

Are you maybe referring to 10ms NETWORK packet delay? All TVs or projectors use buffers, and it takes time for information to travel around serial cables.

Network delay is inconsistent, but electronic delay is not.

Re: An update on Android's audio latency

#129

Post by mrwoggle »

kevingadd wrote: post #26
com2kid wrote: post #25

It'd be nice if something was done about the extra 100-200ms (!!) of latency that Bluetooth headsets can add[1]. I understand this is largely a problem from the manufacturer problem, but I'd love to see Google lead the way with some sort of certification program, or even make their own low cost BT chipset for 3rd party headphones to use, to improve the situation. Of course Android is already world's better than deskt…

There are low latency bluetooth protocols, if you sort by latency on rtings for aptx-LL you can see some headsets are down below 40ms. Of course, this relies on both the host and the headset having support for the protocol and being engineered well. SBC and aptX just aren't designed for low latency, and low latency is something that can't be hacked into every codec after the fact.

What about LC3? It was announced a year ago?
Post reply on HN