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
