Re: Do not want multiple clients mixing my audio
Re: Do not want multiple clients mixing my audio
- Subject: Re: Do not want multiple clients mixing my audio
- From: John Johnson <email@hidden>
- Date: Fri, 14 May 2010 16:16:39 -0500
> Don't know whether I completely understand what you're aming for, but it
> seems you can iterate the connected clients and access their sample
> buffers directly. However, I didn't try that yet.
Yes I found this too. I've been experimenting with doing this in IOAudioEngineUserClient sublass, particularly performClientIO(). Here you can take the bufferSetID that's passed in, get the IOAudioClientBufferSet, which among other things contains the input and output buffers. What I'm currently trying is setting the audio format to not-mixable. From what I gathered, when the audio is set to non-mixable, then the mix buffer that is passed to the engine in clipOutputSamples() is simply the source buffer. I am still looking into what this does exactly. Do you have any insight?
> FWIW, I started a little project some time ago which implements a
> kernel-space driver and loops back audio to userspace, in full-duplex.
> From there, it is transported to a PulseAudio daemon. This whole thing
> is totally unstable and not suited for any real use yet, but I'm
> planning to continue work on it. PulseAudio also needs some changes in
> the API though.
This project is surely interesting, and is doing some of the same stuff I'm doing :) I surely appreciate you sharing this, I'm not too sure I would have found it otherwise, and solid examples of the more esoteric workings of device drivers are hard to come by (translation: not found).
> In particular, have a look what kext/PAStream.cpp does. It subclasses
> IOAudioStream and keeps track of connected users. Again - this is
> untested, don't try this at home :)
Indeed, I do the same thing here. One question I asked earlier was how reliable was "IOUserClientCreator"? Here, I parse out the pid, and leave me with just the name after the comma, and use it to keep track of connected clients. Also, depending on the client, if it's one that the device "knows" of, it can do some special things.
> I would appreciate any feedback. In case your project is also going to
> be free software, you could of course also think about integrating your
> ideas into my project, make it more versatile etc. The userspace daemon
> could be completely replaced by anything else, while keeping the kernel
> driver common.
Yes, my project will be free, although not open source. But as I have become quite interested in the Audio IO model on OSX, I would enjoy helping any way I can. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden