The jack modules are unusable in a low-latency setup.
I have come up with a patch for the sink. For some information that I don't see necessary to repeat here, see my message to the list, where I posted the first version of the patch: http://article.gmane.org/gmane.comp.audio.pulseaudio.general/105
I was told that writing to a pipe may block, and that it causes an undesirable context switch anyway. So I made another version. That didn't work. This is the third version, I added an extra thread that takes care of writing to the pipe. I would have liked to get away with no new threads, since I have no experience of creating threads in a C-like environment. So review carefully at least the start_filling_ringbuffer function where the thread is created. Not that I have experienced any problems, though.
Another thing I'm not sure: do I have to do any memory locking related things? The jack ringbuffer has a locking function, which I have not used. Jack automatically locks the clients' memory, present and future, is that enough? I think I have read somewhere that all memory should be 'touched' before use in the real-time context...
This time the handling of the jack blocksize changes is tested.
The file is completely reordered to my liking, so the patch may not be very easy to follow. For the reviewer's convenience I have also uploaded the resulting file to http://iki.fi/tanuk/tmp/module-jack-sink.c
