'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/]
