[pulseaudio-discuss] PA and OS X

[Daniel Mack]

On Fri, Jul 17, 2009 at 11:55:46AM +0100, Colin Guthrie wrote:
> If I understand you correctly, I think this is effectively doing the  
> same as the Pulse Audio plugin for ALSA.

Comparable, yes, With the (huge) difference that in Mac OS X, you would
need to go all the way thru the kernel and back to provide an audio
interface. ALSA has userspace/library functions for that.

> In this case, the plugin is loaded whenever an alsa client loads up e.g.  
> the plugin runs as the user who is running said application.
>
> This approach sounds a little different.
>
> I'll explain my thinking a bit more and perhaps you can use your  
> knowledge of OSX audio to fit it in correctly!
>
>
> We need two modules (well one really) in PA that do:
>  module-coreaudio-source
> and
>  module_coreaudio-sink
>
> These will be able to record and play sound respectively via a coreaudio  
> backend.

Yes, but those two are totally seperate things. And hence they could
also be done by different people ;)

> We then need a virtual coreaudio "device" (IOAudioEngine) that allows  
> all existing coreaudio apps to play/record via pulse (this is what you  
> suggested above).

Yes.

> This layer should not really depend on a running pulseaudio server on  
> the host machine, so it should not require a specific handling module  
> inside PA which I think is what you suggested (sorry if I got that bit  
> wrong!)

Well, if there is no userspace client caring for the other side of the
kernel module (which is where we need the samples eventually), the
kernel module would just output zeros and swallow away the input
information. There is nothing else it can do, as from a kernel module,
you can't access any network layer or the like.

To use it the indended way, however, you will need the userspace
backend inside PA. Some code to catch audio played back by other
applications and provide it as input to PA. And the other way around:
feed audio provided by PA back to the kernel modules so it can supply
that to any CoreAudio application as record input.

> The "userspace layer" itself, should just be a pulseaudio client: e.g.  
> it should use libpulse to talk to the pulseaudio daemon. This daemon may  
> not actually be running locally, it could be a remote one (i.e. on the  
> network and specified by some kind of config - e.g. the PULSE_SERVER env  
> var).

Ah, I see. Ok.

> Obviously the pulse modules: module-coreaudio-source/sink should be able  
> to identify the "virtual" IOAudioEngine and completely ignore it such  
> that we don't create a universe destroying black hole of doom!

Well. That would then be some fuzzy string match or so. Don't know. Are
you saying you can't build feedback loops with ALSA?

>> Is there any standard internal audio sample format? CoreAudio works with
>> floats all the way, so it would be perfect if there were no further
>> sample conversions included (which is tricky as floats in kernel space
>> are considered evil in Mac OS X, similar to Linux).
>
> Pulse supports quite a few sample formats: see src/pulse/sample.h or for  
> your viewing pleasure:
> http://0pointer.de/lennart/projects/pulseaudio/doxygen/sample_8h.html#41051ceaa5cfbe60c9b176deb7bfed0e

I'd take the floats then and keep the kernel code free of conversion
hazzle.

> Really looking forward to your contributions :D

I can't promise to much attention at the moment as I'm super busy, but I
hope to get something together soon :)

In the meantime, there is some work needed to build the git version on
Darwin, it does indeed not work out of the box.

Daniel