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: Jeff Moore <email@hidden>
- Date: Thu, 11 Jan 2007 12:16:23 -0800
On Jan 11, 2007, at 2:52 AM, Stéphane Letz wrote:
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?
Yes, but just what's in the PublicUtility folder.
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?
There aren't any current plans to do something like that, but the
request has been heard.
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.
That probably has more to do with the content of the properties in
your device than whether or not you are sharing code with the HAL. For
example, kAudioDevicePropertyDeviceCanBeDefaultSystemDevice is only
one aspect of whether or not a device can be the system default output
device or not. The other aspects include not being hogged, having
output streams and having at least one of those streams report a
mixable, linear PCM format. Also, if the streams report a terminal
type, it has to be one that is considered "general purpose", which
basically means that it isn't using the constants representing
embedded devices.
- 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.
Honestly it's not, but that doesn't make it any less cool or useful.
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?
That hook is kAudioDevicePropertyConfigurationApplication. AMS will
show a button to launch the indicated app if this property is set.
Beyond that, the request to make the UI pluggable has been noted.
--
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