[pulseaudio-discuss] Wakeups / ppolls

[David Henningsson]

Trying to reduce the number of wakeups pulseaudio does - and 
specifically so in low-latency scenarios, here's the wakeups done for a 
typical packet roundtrip:

1) ALSA thread wakeup: time to fill up.
ALSA thread sends message to main thread that shm data can be released.

2) Main thread wakeup: message from ALSA thread.
Main thread sends message to client that shm data can be released.

3) Main thread wakeup: iochannel is now writable again.

4) ALSA thread wakeup: time to fill up.
ALSA thread sends message to main thread that more data is needed.

5) Main thread wakeup: message from ALSA thread.
Main thread sends message to client that more data is needed.

6) Main thread wakeup: iochannel is now writable again.

7) Main thread wakeup: data from client.
Main thread reads header of message.

8) Main thread wakeup: data from client.
Main thread reads rest of message.
Main thread sends message to ALSA thread with new data.

9) ALSA thread wakeup: new message from main thread.
The new data is added to the implementor buffer. At this point there is 
no reason to fill up, so we just go back to sleep.

----

So, given this, in priority order:

  A) what bothers me most are the wakeups at 3) and 6), which feel 
completely unnecessary. They also cause wakeups in the client 
application, so fixing that could also optimise things there.

  B) Second is the two-step read (which, btw, also happens on the client 
side). I tried to optimise this too a while ago but ran into trouble 
with the with_creds thing, because I'm not sure how that works so I'm 
afraid of breaking something.

  C) Third, when there is a new data from the client but the ALSA thread 
does not immediately need this data, one could consider not waking up 
the ALSA thread at all. The thread can process the new data when it's 
time to fill up instead.

  D) Fourth, in this scenario I asked for 20 ms latency and 
PA_STREAM_ADJUST_LATENCY. That results in a sink latency of 5 ms, and 
with a watermark of ~2 ms, that makes the ALSA thread wake up every ~3 
ms. (This can in turn result in an shm release packet, request for more 
data, or both.) One could revisit this and see if it is possible to wake 
up less often. Or perhaps if the shm release and request could be 
synchronised somehow - maybe the shm release could be deferred until 
next request for more data or so?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic