3 ms·

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

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.

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 ago
    Are you saying there is still a use case for going straight to ALSA without something in the middle?
alpb 6y ago
At Google it typically manifests itself as "Advancing our amazing bet" https://news.ycombinator.com/item?id=12792928 https://news.ycombinator.com/item?id=12792928
cout 6y ago
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.

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 ago
  Are you saying there is still a use case for going straight to ALSA without something in the middle?

alpb 6y ago

At Google it typically manifests itself as "Advancing our amazing bet" https://news.ycombinator.com/item?id=12792928 https://news.ycombinator.com/item?id=12792928

cout 6y ago

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.