Re: Need help deciding what kind of driver is most appropriate
Re: Need help deciding what kind of driver is most appropriate
- Subject: Re: Need help deciding what kind of driver is most appropriate
- From: "Nick Hebner" <email@hidden>
- Date: Fri, 18 Aug 2006 15:30:09 -0700
Ok, that is what I figured. I have been looking at Jack, and have noticed that implementing a HAL plugin is not an easy feat to accomplish, so I wanted to be certain that this is the path that I want to take before starting on it.
Now about HAL plugins:
From what I have gathered, CoreAudio creates an instance of my plugin, and each application that uses my driver creates an instance as well (correct?). What I dont understand is how these instances interact, if they do at all. What is the point of having multiple instances?
On 8/18/06, Jeff Moore <email@hidden> wrote:
I don't think it would be very practical to do this in the kernel. The
primary reason why is that you need access to the real hardware
devices too. All that support lives out in user space. So even if you
wrote a driver that implemented the fake device, you still have to
send the data back out to user-space in order to send it to the real
device. Plus, in the kernel, you lose all knowledge of which app's
audio goes to which device, so you'd have no way to properly respect
the app's wishes as to which device it audio goes out.
BTW, I believe that Jack does exactly what you want. You might want to
take a look at that project since it is, I think, open source and
available up on SourceForge.
On Aug 18, 2006, at 1:10 PM, Nick Hebner wrote:
> On 8/18/06, Jeff Moore <email@hidden> wrote:
>
> On Aug 18, 2006, at 10:19 AM, Nick Hebner wrote:
>
> > I am developing an application which will allow control of audio
> > streams for each running application that has any from a central
> > location. For instance, volume could be controlled in iTunes from my
> > application. To accomplish this, I want to create a driver which
> > will just pass audio data through it to the real audio drivers, but
> > will be modified first by my driver in some way. My driver needs to
> > communicate with my application all audio streams that are open, and
> > provide mechanisms for controlling them. I have a few questions
> > about how I should implement this.
> >
> > 1. What type of driver would be most appropriate for this, a regular
> > IOAudioDevice driver, or a HAL plugin?
>
> It would probably be easiest to do this as a user-land driver that
> sends the data to a server for processing.
>
> > 2. How can I pass data from my driver to the real audio drivers?
>
> If you are in user-space, you can use an instance of AUHAL or directly
> use the HAL itself.
>
> How might this be accomplished in kernel mode?
>
> > 3. How does an application communicate with the global instance of a
> > driver (IOServiceOpen? Custom properties?)?
>
> If you are in user-space and you want to talk to the daemon, you'd use
> Mach IPC or some other user-land IPC API.
>
> If you are in the kernel, this done by the user-space entity opening a
> connection to the driver object with IOServiceOpen. Inside the kernel,
> this turns into the driver allocating an IOUserClient (or purpose
> built subclass) object that acts as the conduit between the two
> worlds.
--
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