An update on Android's audio latency • Hacker News Board

Re: An update on Android's audio latency

#111

Post by snvzz » Sat, Mar 06, 2021, 7:57 AM UTC

bsder wrote: post #97

snvzz wrote: post #94

40ms is way too much. To put it in perspective, at 60Hz, that's almost 3 frames of video. 10ms would start to be useful for music, but I wouldn't call it good until it was below 2ms, which is what I run my jackd setup (which requires linux-rt) at. I'm afraid we won't see good latency until Android moves away from Linux. The good news is that this is bound to happen, sooner or latter, as Fuchsia exists.

Speed of sound is one foot per millisecond. 40ms is 40 feet. Bands play with that kind of separation all the time.

>Bands play with that kind of separation all the time.

Shortcutting this latency is one of many reasons musicians wear earplugs on stage.

Re: An update on Android's audio latency

#112

Post by _flux » Sat, Mar 06, 2021, 8:00 AM UTC

userbinator wrote: post #96

klodolph wrote: post #93

Earlier quoted context omitted.

> I read through the whole article and that's the most detail given about any testing methodology; I don't see any more description of how these numbers are being measured. The details usually aren’t that interesting. What you can do is record an input signal, pass the signal through to the output, and wire the output back in to another input. You end up with two copies of the input signal, one delayed by the total r…

It's certainly interesting because they can have a huge effect on the measurement results. For example, with HDA and I suspect other audio codec systems, what you described can be done with essentially 0 delay by configuring the codec to do the in/out mix itself. If you are measuring output from application buffers to input to application buffers, then how big they are and at what sample rates and bit depths will als…

Certainly nobody would then agree this is measuring the latency of the audio _system_, it would only measure the latency of the audio device, right?

I think we can give the benefit of the doubt and assume they are not trying to actively deceive.

Re: An update on Android's audio latency

#113

Post by morsch » Sat, Mar 06, 2021, 8:03 AM UTC

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.

Re: An update on Android's audio latency

#114

Post by _flux » Sat, Mar 06, 2021, 8:03 AM UTC

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…

Some vendors, e.g. Samsung, have done some hacks around there, providing more precise audio controls if you drag the audio slider by hand.

I don't know if there are any programmatic system-wide ways to do the same (every app can implement it in their software mixer though). I haven't had great experience with third-party solutions that obviously cannot integrate with the OS at the same level.

Re: An update on Android's audio latency

#115

Post by cout » Sat, Mar 06, 2021, 8:29 AM UTC

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 would be happy if something could be done to prevent audio latency for all devices on my system from permanently increasing if I ever connect a bluetooth audio device.

On Linux, I have to restart pulseaudio after using Bluetooth audio, otherwise retroarch is unplayable.

BTW where are you getting numbers for 200ms latency being average on desktop? My understanding was that latency is typically around 40-50ms on desktop if you are using analog speakers.

Re: An update on Android's audio latency

#116

Post by Lucasoato » Sat, Mar 06, 2021, 8:35 AM UTC

TheRealSteel wrote: post #101

Drakim wrote: post #16

Earlier quoted context omitted.

Emulators of old retro games also care about audio latency, as the emulated audio is generated on the fly by a turning machine, which makes it very hard to match visuals to audio if there is inherent audio latency.

I was very sad when I got a Galaxy Note (R.I.P. Note line) and Elite Beat Agents was unplayable due to audio lag. It makes sense, but it is a shame.

Damn, Elite Beat Agents was such a good game, I cried like a baby in the stage with You're My Inspiration.

Re: An update on Android's audio latency

#117

Post by cout » Sat, Mar 06, 2021, 8:40 AM UTC

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…

Latency on calls over cellular networks is already very high (my subjective experience). But we humans are good at working around it when it's just two people - wait for the other person to finish speaking before you speak, and the other person might have a little longer delay before hearing your response.

If there are multiple parties on the call, this breaks down, because if two people want to speak, they both start talking and don't realize it for a little while.

On video calls this also breaks down, because either video and audio get out of sync (like with zoom) or you get odd artifacts in either the video or audio as they are kept in sync.

Re: An update on Android's audio latency

#118

Post by Drakim » Sat, Mar 06, 2021, 8:48 AM UTC

_flux wrote: post #110

Drakim wrote: post #16

Earlier quoted context omitted.

Emulators of old retro games also care about audio latency, as the emulated audio is generated on the fly by a turning machine, which makes it very hard to match visuals to audio if there is inherent audio latency.

If just matching is desired then you can just buffer video frames; all audio frameworks provide means to synchronize video and audio. Of course, it probably makes the experience just worse if the delay is silly long..

By doing that you create input lag for the game.

Re: An update on Android's audio latency

#119

Post by cout » Sat, Mar 06, 2021, 8:51 AM UTC

AceJohnny2 wrote: post #2

Usually, "an update on [blank]" is euphemism for said product getting cancelled. More to the point, one of PulseAudio's claims was that they consumed less CPU than Android's audio pipeline. With the recent hyped PipeWire, I wonder how that compares to Android's Oboe.

Where was that claim made (for pulseaudio vs Android)?

Hearing any claim that pulseaudio uses less cpu than some alternative makes me blink. For years I could not use pulseaudio while playing games, because it would eat 99% cpu and I only had one cpu core. Things are better now that I have eight cores, but I don't know if that's due to the extra cores or if pulseaudio has improved.

I tried jackd, but the documentation is overwhelming.

I remember ESD and OSS working just fine, but I was young and maybe I was just happy to get audio at all. I grew up with blips and bleeps coming out of the PC speaker.

Re: An update on Android's audio latency

#120

Post by ungamedplayer » Sat, Mar 06, 2021, 8:51 AM UTC

theshrike79 wrote: post #103

kllrnohj wrote: post #78

Earlier quoted context omitted.

> That macs are more stable in day-to-day operation is not really a bold claim though. It absolutely is. Do you have any data to back up the claim? Anecdotally windows 10's stability seems vastly superior, especially with every release of MacOS seemingly regressing further and further.

I got the idea that "stability" here doesn't refer to crashing, but more about the fact that the computer behaves in a consistent manner. You won't get a sudden I/O or CPU load during important operations for example.

Thats also untrue of osx, spotlight indexing, cron jobs, etc.