On Wed, 2013-03-20 at 10:06 +0100, David Henningsson wrote: > 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. OK, I can see this being useful in the use case that Thomas talked about: it makes it easier to put all audio processing into a separate thread, since you save the thread and mainloop setup/teardown code, at the cost of losing the ability to add any other event sources to the mainloop. This is actually how the JACK API works, I think. I'm not against adding this new functionality. -- Tanu
