[pulseaudio-discuss] PA and OS X

[Colin Guthrie]

'Twas brillig, and Daniel Mack at 17/07/09 11:12 did gyre and gimble:
> On Fri, Jul 17, 2009 at 08:23:55AM +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Daniel Mack at 17/07/09 07:46 did gyre and gimble:
>>> And I could probably help here, too - I've been hacking Mac OS X audio
>>> drivers (kexts) in the past and know about some nasty pitfalls.
>> Awesome! This is exactly the kind of experience we need.
> 
> What I could start with is a little kernel extension that registers a
> CoreAudio IOAudioEngine (the representation of a sound card in Mac OS X)
> and loops the audio material back to a user space layer. Audio would be
> transported using shared memory, and other information like sample rate
> change notifications would be done with something similar to ioctl()s.
> 
> That userspace layer would then be put into a PA audio plugin which is
> then able to record and playback audio and interact with every possible
> CoreAudio client application. Does that sound feasible? What would be a
> good name for it (something to distinguish between this one and the one
> using the CoreAudio userspace API)?

If I understand you correctly, I think this is effectively doing the 
same as the Pulse Audio plugin for ALSA.

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.


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).

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!)

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).


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!



> 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'm not really super proficient in the pulse stuff at this level (I've 
developed toys and modules, but the core stuff I've only just glanced 
over). Mezcalero/Lennart is the real pro, but he's on holiday right now.

Our IRC channel is the best place to discuss things interactively and 
has a few of us regulars generally chatting too.

#pulseaudio on free node... I'm coling. :)

Really looking forward to your contributions :D

Cheers

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]