[pulseaudio-discuss] PA and OS X

[Tanu Kaskinen]

la, 2009-07-18 kello 14:05 +0200, Daniel Mack kirjoitti:
> I've put some pieces together now and what I got is
> 
> - a kernel module that loads and unloads fine and offers a virtual
>   stereo soundcard which can be selected by any CoreAudio application.

So this provides the interface for native Mac apps to connect to
pulseaudio. Naming these things would probably be useful. I think "the
kernel module" and "the kernel module's CoreAudio interface" might be
appropriate names for this.

> - a user space interface to share the ring buffers with application so
>   that audio can be transported in and out.

What's this again? Is this "the other side" of the kernel module that
provides the interface that will be used by the component that will
communicate with the pulseaudio server using libpulse? Could this be
called "the kernel module's user space interface"?

> - a skeleton for an
>   application that connects to that interface and maps the shared memory
>   buffers.

And this is the beginnings of the previously mentioned component that
uses libpulse? Maybe "the bridge" could be the name for this?

<snip>

> 2. The CoreAudio backend needs a clock for the internal ring buffer
> motor. There are two different possible aproaches. Either the audio
> driver clocks itself using a timer and then is the clock master to the
> user space. Or the user space appliction obtains the clock from PA and
> clocks the kernel module. I'm sure there is a clearly preferred way to
> go for PA, but I'm uncertain which one that is. And how is that handled
> for both directions?

Sinks and sources provide the clocks in PA. That means the original
clock source is in most cases the sound card. The clients (in this case
the bridge) register callbacks that are called when the server wants
more data (playback) or when there is some data available to read
(record). Did this clear things at all? Hopefully the CoreAudio API
matches this model so you don't need to resort to any complicated tricks
- so if CoreAudio applications communicate with the kernel module using
callbacks, the calls can be hopefully be just propagated from the bridge
to the kernel module and from there to the application.

If you haven't done so yet, read the libpulse documentation at
http://0pointer.de/lennart/projects/pulseaudio/doxygen/ (from the front
page go to the Asynchronous API section).

-- 
Tanu Kaskinen