Re: App + Device Driver (having design issues)
Re: App + Device Driver (having design issues)
- Subject: Re: App + Device Driver (having design issues)
- From: Jeff Moore <email@hidden>
- Date: Fri, 7 May 2010 11:52:39 -0700
On May 7, 2010, at 10:40 AM, John Johnson wrote:
>> Its called JACK, its GPL'ed and its been around for nearly 7 years.
I would tend to agree with Paul that the user-land driver model is probably the best route for something like this. It gives you the most control over things. It would eliminate your feedback problem, for example. It would also keep you from having to do any kernel programming, which is always a good thing in my book.
Basically, you'd implement a client/server model. The server (your app) would publish some shared memory that the user-land driver in the client (the target app) would use to send the data to the server. How you do the timing between the processes is up to you, and there are a variety of ways to do it (sockets, mach messages, timers, etc). Just ping-ponging between a real time thread in each process via mach messages isn't too terribly difficult to implement and can be pretty efficient. But you can go with what you are comfortable with.
FWIW, JACK implements a good amount of exactly this sort of thing which is why Paul was suggesting it.
> Thanks Paul, but 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.
> 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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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