[pulseaudio-discuss] Expand the simple API?

David Henningsson david.henningsson at canonical.com
Wed Mar 20 02:06:55 PDT 2013

On 03/20/2013 09:49 AM, Tanu Kaskinen wrote:
> On Wed, 2013-03-20 at 09:32 +0100, David Henningsson wrote:
>> On 03/20/2013 08:57 AM, Tanu Kaskinen wrote:
>>> On Tue, 2013-03-19 at 13:20 +0100, Thomas Martitz wrote:
>>>> Am 19.03.2013 10:56, schrieb Tanu Kaskinen:
>>>>> 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.
>>> The applications would still need to be aware of the threading.
>>> pa_simple_read/write() is expected to be done from the main thread, so
>>> the application necessarily needs to implement some communication method
>>> between the two threads.
>>   From what I can see, there is no such restriction of the simple API. It
>> does not have a concept of a "main thread", so as long as you don't call
>> into the simple API from two threads at the same time you should be just
>> fine, e g, it would be perfectly valid to do pa_simple_new in one
>> thread, and later call pa_simple_write from another thread.
> pa_simple_write() calls pa_threaded_mainloop_wait(), and
> pa_threaded_mainloop_wait() has this assertion:
> pa_assert(!m->thread || !pa_thread_is_running(m->thread) || !in_worker(m));
> The in_worker() check will fail, if pa_simple_write() was called from
> the callback context.

Sure. You said "pa_simple_read/write() is expected to be done from the 
main thread", but you meant more like "pa_simple_read/write() is 
expected to be done from any other thread than the callback context"?

A pa_simple callback API, if implemented, I would envision would supply 
a data pointer and length, and ask for the callback function to either 
read that out (record) or fill it in (playback), and to do so without 
calling into the PulseAudio API at all.

And with a big fat note that it is being called from a separate thread 
and that the pa_simple API cannot be used from the callback function.

David Henningsson, Canonical Ltd.

More information about the pulseaudio-discuss mailing list