Re: IOAudioFamily : driver structure
Re: IOAudioFamily : driver structure
- Subject: Re: IOAudioFamily : driver structure
- From: Phil Montoya <email@hidden>
- Date: Tue, 21 Sep 2004 10:09:59 -0700
Exactly Nick,
Forums like these are really a good source of information and you have
the experts who participate and provide valuable insight. Jeff has
been very responsive in answering my questions and is an invaluable
source of good information.
I was confused and made the same mistake. AudioDevice in driver land
means IOAudioDevice which is composed of IOAudioEngines which are
composed of IOAudioStreams. In HAL land the AudioDevice really means
IOAudioEngine. This is a subtle but very important distinction and
once this is explained everything makes sense.
-Phil
On Sep 21, 2004, at 1:38 AM, nick wrote:
Thanks a lot for the info, it's a BIG help!
I had started my driver as 2 separate AudioEngines, thankfully I
haven't spent too much time implementing that yet so I shouldn't lose
too much time :)
Shouldn't this information be in the "Writing Audio Device Drivers"
document? It seems pretty crucial to me! The document actually
encourages developers to use multiple AudioEngines..
Regards,
Nick
On 20 Sep 2004, at 22:24, Phil Montoya wrote:
The first rendition of our core audio driver achieved exactly the
results we intended and it worked as expected using Final Cut Pro.
Now that we had a "core audio" driver it was our assumption that
other apps who used core audio would work with our driver. To our
dismay we discovered this isn't necessarily so. We then took the
extra step to fix this so that our driver could be as compatible as
possible with as many applications as possible. To say we had an
unusable driver is inaccurate it actually worked very well with the
application it was written for. It just didn't work well with
everything.
The moral of the story is that you can have a perfectly working core
audio driver that doesn't work with all core audio applications.
And if the assumption is a native full duplex engine then your
hardware better cooperate or this isn't possible.
-Phil
On Sep 20, 2004, at 12:13 PM, Jeff Moore wrote:
If you choose present your device as multiple engines, you should be
prepared for many apps not being able to use your other engines. For
some devices, this is fine and dandy and achieves what the device
developer is looking for. For other devices, like Phil's for
instance, it results in an unusable driver that doesn't come close
to achieving the desired results.
You, being the driver developer, need to figure out exactly what you
want to present to applications and then use the tools the IOAudio
Family provides to achieve that.
On Sep 20, 2004, at 10:26 AM, Phil Montoya wrote:
The single full duplex engine is more efficient and provides you
with a more compatible driver. However in order to use a single
engine it is critical that your hardware provide a single time
stamp for all of the streams (both input and output). There is
just one call to start and stop the engine and the timing is shared
among all streams.
Initially I created two engines one for input and the other for
output mainly because our hardware had separate wrap interrupts for
the input and output buffers. I discovered this driver worked in
most applications but there were some applications that assumed the
output device was full duplex and could also do input. Logic
Platinum 6 is one example, it never saw the input engine or input
stream.
I rewrote the driver to have a single engine and life is better.
--
This message and any attachments are confidential to the user of the
e-mail address to which it was addressed. The sender does not accept
liability for any errors or omissions in the context of this message
which arise as a result of Internet transmission. Any opinions
contained in this message are those of the author and are not given or
endorsed by Focusrite or office through which this message is sent
unless otherwise clearly indicated in this message and the authority
of the author to so bind the Focusrite entity referred to is duly
verified.
_______________________________________________
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
_______________________________________________
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