that solution doesn't work for me.
Nothing you've said would lead me to this same conclusion. Quite the contrary in fact, it seems to me that something along the lines of the client/server approach that JACK takes is ideally suited to what you want to do.
According to that idea, Soundflower wasn't even necessary, because Jack provides all of it's functionality too ;) Yes, Jack would seem ideally suited, but for my situation I need to implement a kernel-level driver. I could really use some information on how to do this using the Soundflower model, and multiple engines or streams like I mentioned. _______________________________________________
Some quick info about what the objects are. Each IOAudioEngine attached to an IOAudioDevice shows up as a separate device in the HAL. An IOAudioStream represents a single stream of data on an Engine. All the Streams on an Engine are synchronized. Instantiating new IOAudioEngines and IOAudioStreams is done with the usual IOKit techniques. You can do it any time you like. In fact, you could even create a user-client operation that spawned them on the fly. There's nothing really special here. It's all pretty vanilla driver stuff. You should consult the IOKit documentation and sample code for more information on the topic. At any rate, I have no particular advice to give you on this front as I'm not sure what you are intending to do with the multiple engines and streams. It won't solve your feedback problem necessarily, so you'd probably need to elaborate a bit.
To elaborate, the reason I am asking about multiple engines or streams is this. I need a way for the main app to send (output) audio to the driver and the driver to know that it is intended for App 1 and route it accordingly. So my first idea was this:
1) Create 2 input streams and 2 output streams 2) App 2 from the diagram would send to device on output stream 1 (output because the device is set as an output device) 3) The device would know that anything coming in on output stream 1 is meant for main app, so it saves in buffer designated for main app 4) Main app asks for input on input stream 1 5) Driver knows that input stream 1 is designated for the main app, so it sends the saved data from output stream 1
6) Main app sends to device on output stream 2 7) The device would know that anything coming in on output stream 2 is meant for App 1 from the diagram, so it saves in buffer designated for App 1 8) App 1 asks for input on input stream 2 9) Driver knows that input stream 2 is designated for App 1, so it sends the saved data from output stream 2
Though when trying to implement this, it seemed horribly complicated, as I could see the only way to differentiate between streams was by channels. But the main idea is for the driver to be able to distinguish who the data coming in is meant for so that it can route it to the correct app. I don't need to know the code to do it, just the design concept. This would be extremely helpful and very much appreciated.
Thanks for your thorough explanation too, Jeff.
John |