[pulseaudio-discuss] sink/source implementation for pull-io audio processing

[Lennart Poettering]

On Tue, 03.11.09 10:54, Daniel Mack (daniel at caiaq.de) wrote:

> Hey,
> 
> I'm currently hacking on modules for CoreAudio sink/sources and wonder
> which way to go for the actual audio buffer transfer.
> 
> CoreAudio is implemented in a asynchronous pull-io fashion, which means
> that the user registers a callback (IOProc) to be called for the device
> whenever there is a specified amount of data available and/or wanted,
> respectively. That's all fairly straight forward.
> 
> As the PA sinks/sources are set up to match the sample format used by
> CoreAudio's IOProc, there is actually nothing more left to do inside
> this callback than copying the buffers from one end to the other when
> I'm called and then inform PA about new data arrival.
> 
> Which API would cause as less overhead as possible? I didn't fully
> understand the magic behind the PA RT threads yet, and I doubt I need that
> at all as CoreAudio's IOProc is already called from a _very_ highly
> priorized thread.

This is actually similar to the JACK situation. On JACK too, the API
allocates the thread and we need to make the best of it. In the Jack
case we work around that by playing ping-pong between two RT
threads: the one that is created by libjack and the one that is
created by PA. This is actually really bad, since this means one
additional context switch, and we really would prefer to do without
it.

The PA core actually does not require that it runs an RT thread that
was created by itself, we are actually very flexible on this and could
run fine with a foreign thread. However, what is important is that
there is a way so that the PA core can wake up the RT thread at any time
and cause it to execute code then. Unfortunately JACK currently does
not allow that, the RT thread can only be woken up by the JACK server,
not by our PA core.

Now the question is: how much control does CoreAudio actually give you
for that high prio thread? Is there any chance you can trigger from
the PA main thread that some code is run inside the RT thread
CoreAudio maintains? That means to things: firstly, there needs to be
a way to wake up the RT thread from another thread, and secondly that
some arbitrary code can be executed in the RT thread then.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4