3 ms·
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 wi
by raphlinus 6y ago
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, for example, PipeWire (which also looks good). Do keep in mind that constraints are different on mobile, and things like power management can and do get in the way of down-to-the-wire latency.
- jancsika 6y ago> 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 round-trip latency. They then piggy-back on that well-understood concept to introduce the concept of "tap-to-tone latency" and show measurements for that. Almost to the case, the times I've read a back-and-forth conversation where the word "latency" is used unprefixed, the commenters might as well be describing the warmth of vinyl recordings. Often they are simply describing an integer they typed into a widget or config file. On several occasions I've witnessed users insert Jack between a single application and ALSA because "that's what the professionals use." These are knowledgeable users who want as little latency between the system and their ear as possible.
- cout 6y agoAre you saying there is still a use case for going straight to ALSA without something in the middle?