On Tue, 2013-03-19 at 09:40 +0100, David Henningsson wrote:
> 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?
I'd be OK with adding pa_simple_writable/readable_size(). I believe the
multi-threading aspect of adding the write/read callbacks unavoidably
makes writing applications not-simple, so the simple API probably
shouldn't have those callbacks.
--
Tanu
