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 14:23:39 -0700
On May 7, 2010, at 1:10 PM, John Johnson wrote:
>>> 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 don't mean to dig, but why? Honestly, I can't think of a single good reason for you to be in the kernel. What advantage do you think you have from being in the kernel vs. doing things in user-space?
Note that you don't have to use JACK, per se, but the techniques that JACK is using seem way more appropriate for your application than a kernel driver. I'm a bit puzzled at why you don't even seem to want to try this method out.
>>> 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.
IOKIt has the IOUserClient class of objects to convey information between a driver and it's client in user-space. Your driver would need to have a sub-class of IOUserClient and then your code in user-space would have to know how to locate the driver, open a user-client, and feed down the appropriate information. Fortunately, this is all vanilla IOKit programming. So the IOKit docs and examples are what you want to look at to learn more.
> Basically, I am adding this feature. What I am making is a Soundflower that accepts multiple devices, a Soundflower on steroids ;) I had already looked into Jack and was forced to dismiss it, as nice as it was. Because if I use a kernel driver, it will be compatible with ALL apps, not just those that allow userland drivers.
Ah. Now it is clear. This is a total misconception on your part. User-land drivers and kernel drivers are completely equivalent, save for aggregate devices. An app that can use one type of driver can use the other. Apps may have issues with JACK specifically, but that should not be used paint all user-land drivers in a bad light.
Consequently, I still say that you are best served with the client/server model rather than mucking about in the kernel.
--
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