I spent yesterday afternoon writing a small PulseAudio client using the
asynchronous API and found that it was a few things to setup; the
mainloop, the context, the stream, callbacks etc.
Just to recap, there are three strategies for feeding data to PulseAudio:
* Blocking:
pa_simple_write(data, length);
or:
while (length > 0) {
while (pa_stream_writable_size() == 0)
pa_mainloop_wait();
pa_stream_write(data, pa_stream_writable_size());
data += pa_stream_writable_size();
length -= pa_stream_writable_size();
}
* Polling:
every now and then do:
pa_stream_write(data, pa_stream_writable_size());
* Callback:
pa_stream_set_write_callback(my_write_callback);
pa_mainloop_run();
my_write_callback(size_t length) {
pa_stream_write(data, length);
}
Looking at the client code, it seems very simple to add
pa_simple_writable_size() to the client API, and thus enable the polling
scenario for the simple API too.
Even the callback scenario - which is the most efficient one, I would
assume - seems not too difficult to implement in the simple API, as long
as the user is aware that the callback will be called from a separate
thread (as the simple API is based on a threaded mainloop).
Sure, more options makes a simple API less simple, but at least the
pa_simple_writable_size API wouldn't hurt to implement IMO. The
user-friendliness of providing this outweighs the possible lack of
simplicity. Or what do you think?
For recording streams; the same reasoning applies.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
