Re: Jack and CoreAudio (was Mirroring Audio Output)
Re: Jack and CoreAudio (was Mirroring Audio Output)
- Subject: Re: Jack and CoreAudio (was Mirroring Audio Output)
- From: Stéphane Letz <email@hidden>
- Date: Thu, 11 Jan 2007 11:52:09 +0100
------------------------------
Message: 6
Date: Tue, 9 Jan 2007 14:35:39 -0800
From: Jeff Moore <email@hidden>
Subject: Re: Jack and CoreAudio (was Mirroring Audio Output)
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Thanks a lot for anwreing
On Jan 9, 2007, at 1:31 PM, Dan Nigrin wrote:
- developing a user-land based CoreAudio driver is difficult!
No doubt about that, but in order to offer you the same about of
integration the IOAudio support has, you have to have full access to
patch in, which is what the user-land driver API gives you.
Unfortunately, that comes with the responsibility of living up to the
full semantics of the API without a whole lot of assistance or
documentation.
Definitely a tough row to hoe, but we are happy to help where we can.
I think one way to "get access to the HAL internals" is to "share"
code. The CoreAudio SDK already provide developers a lot of code to
be used in applications. I guess part of this code is also used in
the HAL?
The difficulty of developing a user-land driver (implementing the
<CoreAudio/AudioHardwarePlugIn.h>.) is that a lot of "generic" code
has to be implemented for instance: to express the channels layout of
the driver, the fact that the driver can be system default,
allocation of internal audio device ID and audio streams ID and so
on.....
A real improvement would be to have a *generic* implementation of
this basic part, to be "derived" (in C++ sense) or any other kind of
code reuse. Would this be possible to build this generic
implementation by using part of the code found in CoreAudio SDK
PublicUtility folder? Is this something Apple would be interested to
help make happen?
A lot of code that is probably also part of the CoreAudio HAL layer
had to be rewritten.
I think that you are assuming a lot. There aren't any secret APIs or
anything like that. In fact, the IOAudio support itself is actually
just another version 3 implementation of the
AudioHardwarePlugInInterface in <CoreAudio/AudioHardwarePlugIn.h>.
In this case, we definitely eat our own dog food with these APIs.
Or share a common code base ((-:
Keeping a high degree of quality and compatibility with all possible
CoreAudio clients has become more and more difficult to achieve.
Moreover internal changes between OS releases (for example Panther
and Tiger) caused us more problems.
That's unfortunate, but I don't recall the other users of this API
reporting any issues along those lines (granted that was a while ago,
so memory is hazy). My bet is that a lot of your troubles probably
stem from the assumptions you've made in your implementation about how
things should work.
We had problem concerning having our driver be the default system
input/output one. Again this would possibly be a common behaviour to
be factorized.
- a Jack-like server system needs a centralized management tool, to
configure different parameters, to give users a centralized view of
all running applications, and to handle audio port connections. This
would typically be a feature to be included in the AudioMidi Setup
kind of tool, but we had to develop a separate tool to realize these
features. As an example, please see some images of a never-
completed prototype (coded by Evan Olcott) that we feel are more in
line with the Apple "experience": http://www.jackosx.com/
prototype.html
.
I don't see your situation all that different from what other hardware
developers are in when it comes to creating a GUI app that configures/
shows off the capabilities of their product. MotU has their little
config app. Metric Halo has theirs. Etcetera. Who better to write that
app but the folks that know their product the best?
kAudioDevicePropertyConfigurationApplication exists specifically to
allow folks to discover and launch these custom apps.
The Jack case is somewhat a bit different since its really a kind of
core feature of the audio layer. Would it be possible to provide a
"hook" in the Audio/Midi setup tool, and especially in the audio
section to add some more UI elements?
Our feeling is is that there is a strong desire to have Jack (or
Jack-like) functionality embedded at the OS level. We think this
would benefit the entire audio OS X community, and since Jack is an
open-source project, we think it could be a good code base for this
purpose. We think also that is it perfectly possible to have a Jack-
like system running side by side with the existing CoreAudio layer,
without any kind of compromises
Personally, I don't understand this sentiment. Why does it have to be
in the system? As I've said, there are ample hooks to allow you to
make it integrate seamlessly without this. I just don't understand
what you get out of it other than some kind of official stamp of
approval?
If that's not in the cards, from our perspective, it would make
things easier for us if we could get access to some more internal
parts of the CoreAudio HAL and AudioMidi Setup tool, or share in any
way part of the HAL stack implementation.
I don't think that getting access to the internals of the HAL will get
you what you think it will. As I said, there aren't any secrets or
hidden functionality. I don't think that there is anything there that
you don't already have access to through the public API. Can you
provide some details about what, specifically, you are looking for?
Best Regards
Stephane Letz
_______________________________________________
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