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
