5 ms·

Given the title, I would have liked to see some in-depth analysis on why the latency is as bad as it is? Which parts of the software stack are causing it? Even

by exDM69 11y ago

Given the title, I would have liked to see some in-depth analysis on why the latency is as bad as it is? Which parts of the software stack are causing it? Even though the Linux kernel is less than ideal for audio, it can still provide a latency low enough for music, ie. 10 ms or less. This is an unbearable situation. There are lots of interesting music apps on the iOS that I would like to use, but only a handful are available on Android. And even if they are available, they are not necessarily usable.

rogerbinns 11y ago
> Which parts of the software stack are causing it? There is a diagram lower down in the article with the components (ALSA, audioflinger etc). http://www.androidpolice.com/wp-content/uploads/2015/11/nexus2cee_Android-Audio-Path-Latency-Superpowered-Audio700px.gif http://www.androidpolice.com/wp-content/uploads/2015/11/nexu...
- dgregd 11y ago
  Actually Android standard doesn't include ALSA. There is a thin sound HAL above ALSA, OSS and other Linux sound technologies. Of course many phone vendors use ALSA to implement Android HAL layer. It seems that Samsung uses its own sound drivers and therefore they have small audio latency compared to other Android vendors.
- exDM69 11y ago
  The infographic looked so much like an ad that I skipped over it. So this is one of the "good" Android audio stacks, getting 36ms latency. But half of that is "wasted" in user space, in AudioFlinger as well as the app ring buffer (which seems pretty big to me). I'd like to see the comparison to a "bad" Android device. Doing some internet searches, I found someone who had plugged in PulseAudio to an Android phone and got 20 ms latency instead of the 170+ ms latency from AudioFlinger on the same device [0]. That's pretty huge. Ideally, there should be no user space middleware component processing audio in between, this could half the latency (according to the diagram), bringing the latency to acceptable levels. But ALSA isn't really intended for routing audio on the fly conveniently (e.g. when plugging/unplugging headphones), so there is some room for improvement too. Overall, the situation is pretty sad. Linux can do better than that but a modern multimedia device (desktop or mobile) has several audio outputs and hot-plugging, which makes the situation rather difficult using ALSA only. And the userspace audio components just aren't great. http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/ http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-f...
kllrnohj 11y ago
cheesy video from google on it: https://www.youtube.com/watch?v=PnDK17zP9BI https://www.youtube.com/watch?v=PnDK17zP9BI tl;dr: it's easier to increase buffer sizes to fix underruns than to fix driver foo randomly disabling interrupts for too long. That, along with not having fast-paths to bypass large parts of the stack (mixer, resampler, audio effects, etc...), and bam, high latency.

by exDM69 11y ago

rogerbinns 11y ago

> Which parts of the software stack are causing it? There is a diagram lower down in the article with the components (ALSA, audioflinger etc). http://www.androidpolice.com/wp-content/uploads/2015/11/nexus2cee_Android-Audio-Path-Latency-Superpowered-Audio700px.gif http://www.androidpolice.com/wp-content/uploads/2015/11/nexu...

dgregd 11y ago
Actually Android standard doesn't include ALSA. There is a thin sound HAL above ALSA, OSS and other Linux sound technologies. Of course many phone vendors use ALSA to implement Android HAL layer. It seems that Samsung uses its own sound drivers and therefore they have small audio latency compared to other Android vendors.
exDM69 11y ago
The infographic looked so much like an ad that I skipped over it. So this is one of the "good" Android audio stacks, getting 36ms latency. But half of that is "wasted" in user space, in AudioFlinger as well as the app ring buffer (which seems pretty big to me). I'd like to see the comparison to a "bad" Android device. Doing some internet searches, I found someone who had plugged in PulseAudio to an Android phone and got 20 ms latency instead of the 170+ ms latency from AudioFlinger on the same device [0]. That's pretty huge. Ideally, there should be no user space middleware component processing audio in between, this could half the latency (according to the diagram), bringing the latency to acceptable levels. But ALSA isn't really intended for routing audio on the fly conveniently (e.g. when plugging/unplugging headphones), so there is some room for improvement too. Overall, the situation is pretty sad. Linux can do better than that but a modern multimedia device (desktop or mobile) has several audio outputs and hot-plugging, which makes the situation rather difficult using ALSA only. And the userspace audio components just aren't great. http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/ http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-f...

kllrnohj 11y ago

cheesy video from google on it: https://www.youtube.com/watch?v=PnDK17zP9BI https://www.youtube.com/watch?v=PnDK17zP9BI tl;dr: it's easier to increase buffer sizes to fix underruns than to fix driver foo randomly disabling interrupts for too long. That, along with not having fast-paths to bypass large parts of the stack (mixer, resampler, audio effects, etc...), and bam, high latency.