[pulseaudio-discuss] Expand the simple API?

[Thomas Martitz]

Am 19.03.2013 10:56, schrieb Tanu Kaskinen:
> 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.
>

It's not unlikely that an application that uses blocking or polling 
methods uses an extra thread for that, which it wouldn't do if it could 
use the callback method. So in this case the callback would simplify the 
application, because the multi threading aspect is not in the 
application logic but in pulseaudio. I don't know how common this case 
is, but I would expect it's rather common.

Best regards.