[pulseaudio-discuss] PA and OS X

[Tanu Kaskinen]

su, 2009-07-19 kello 21:26 +0200, Daniel Mack kirjoitti:
> > > - 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"?
> 
> No, that's actually part of the kext, it's just a part that is not
> mandatory for such a kernel module. Hence I noted it seperately. The
> correct term for that part is 'IOUserClient'.

I understood that it's part of the kext. But what's its role? (Yes, you
explained it above, but I do not understand the explanation.) Is it the
interface that the bridge uses to pass data to/from the kext?

> > > 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
> 
> No, that's fine.
> 
> I was just considering an example like the following:
> 
>  - a client provides a stream recorded from an audio input which has its
>    own clock

I understand this so that the client (a CoreAudio application) records
stuff from somewhere and simultaneously plays the recorded audio to the
kext. Did I understand correctly?

>  - this stream is sent to the 'bridge' (let's say, over the network) for
>    playback (which means it is provided as a virtual record stream to
>    CoreAudio applications).

This part I do not understand. Aren't the kext and the pulseaudio server
the only things that ever send stuff to the bridge? And even over the
network?? There must be something I have understood wrong. What do you
mean by providing a virtual record stream? My association is that the
playback stream is available for other CoreAudio applications to
capture. That would be interesting - the plugin for alsa doesn't expose
the streams to other alsa applications (I don't think alsa has the api
for this anyway).

>  - if the 'kext' would now be able to take any amount of audio material
>    and hence sync to the original clock, that would be good.

This looks to me like the kext would offer CoreAudio applications a
push-based playback api. The pulseaudio api is pull-based, as I
explained in the previous mail. Does the kext possibly offer both push-
and pull-based apis? Anyway, combining the push-based api with
pulseaudio's pull-based api requires the kext to maintain a buffer from
which the bridge reads when it wants to and to which the application
writes when it wants to. If the application should be able to always
push data without blocking (since it has its own clock), you need to do
resampling here.

>  - if the 'kext' clocks itself, there would be some resampling needed in
>    the middle. Which is not as good.

I think I answered this above.

> That whole model does of course not work in case the original data is
> not served by a soundcard but - let's say - from a file. In that case,
> having a clock supplied at the sink whould be mandatory.

A PA sink always provides a clock. Well, some kind of a clock anyway - I
think the file sink asks for more data as fast as it can write to the
disk. (But I believe the file sink shouldn't be used for anything
serious, and AFAIK in practice it isn't really used for anything
non-serious either.)

> Can you follow? ;)
> 
> So what I mean is: there could/should be a flag for each stream
> identifing whether there is a clock supplied on it already. We could
> then take that into account for the kernel module and switch the
> clocking direction if necessary. But I don't know PA, so I can't say if
> such scenarious are things that have been thought of at all.

This "clock-at-both-ends" problem is probably very familiar to anyone
who has been reading this list for a while :) It comes up whenever
someone wants to hook a source directly to a sink. And pulseaudio
doesn't have a good solution for that yet - the clock is always at the
sink/source and nowhere else. I don't think this is going to change
anytime soon, so you're pretty much out of luck. And resampling couldn't
be avoided anyway, the only question is where it should be done at.

> > - 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.
> 
> Yes, more or less. It's not as easy though, because CoreAudio has a mix
> buffer inbetween to serve different applications with different buffer
> sizes. Hence, the kext is likely to be served with overlapping buffers,
> especially when new clients connect. So there must be some abstraction
> that breaks things up into chunks we send to the bridge. That will need
> some consideration.

I'm not sure that is needed (but it may be). Pulseaudio clients can
define per-stream buffering metrics, so it sounds like this might not be
a problem at all. But I'm not an expert here.

-- 
Tanu Kaskinen