[pulseaudio-discuss] Expand the simple API?

[David Henningsson]

On 03/19/2013 10:56 AM, Tanu Kaskinen wrote:
> 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.

Hmm, just found something when looking at readable_size(). In case of 
stream holes, _readable_size() would return more than can actually be 
read by simple_read() without blocking.

Do you think this limitation is acceptable? If not, do you think 
pa_simple_readable_size should just return the length of the first 
memblock like this:

   for (;;) {
     pa_stream_peek(&data, &length);
     if (data)
       return length;
     pa_stream_drop(length);
   }


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic