Re: Curious happening with CAPlayThough
Re: Curious happening with CAPlayThough
- Subject: Re: Curious happening with CAPlayThough
- From: Jeff Moore <email@hidden>
- Date: Fri, 09 Jan 2009 11:57:26 -0800
It is admirable that you are trying to cobble together something using
our sample code. But I think you misunderstand the concept of sample
code here. The goal of sample code is usually not to deliver a
finished, working bundle of code. The goal is to deliver a bundle of
code that illustrates the concepts of the APIs it uses. The fact that
the code actually does something useful is always a welcome and happy
side effect.
The sample code that we write usually stems from some kind of need we
have had when working on the operating system. The
AudioReflectorDriver, for example, started out life as a debugging
tool that was based on the earlier sample driver we used to ship, the
PhantomAudioDriver. Like a lot of tools, it grew and filled out it's
capabilities and made itself generally useful. Eventually, we took
some time and put a few coats of paint on AudioReflectorDriver and
replaced the PhantomAudioDriver in the sample code with it.
I'm sorry that the AudioRefelctorDriver and CAPlayThrough are giving
you fits when you try to cobble them together. I'm pretty sure though
that the core problem is the problem that I was referring to earlier.
Basically the problem is that the fake DMA mechamism the
AudioReflectorDriver uses doesn't account for scheduling latency. This
causes it to drift over time. Note that this is not going to be a
problem that a real driver is going to have as they generally have
real hardware backing them with real DMAs and interrupts that won't be
affected by scheduling latency.
Note that the AudioReflectorDriver's code documents this issue. It
even includes a suggestion on how to fix it. Personally, I believe
that adding the code that corrects for this drift, which is something
a real driver would never have to do, would make the
AudioReflectorDriver actually less effective as sample code. The
reason why is the extra math would obscure the important parts of what
should otherwise be a fairly simple function for a real driver.
On Jan 9, 2009, at 10:00 AM, Stephan M. Bernsee wrote:
Jeff,
I understand that, and I really appreciate Apple's dedication to
providing example projects to build products off of. However, even
if the AudioReflectorDriver is just an example its usefulness is
severely limited by the fact that it doesn't really work for more
than 5 minutes without glitches. I don't see how anyone could easily
create a working product from a broken sample. No pun intended, I am
just a bit frustrated since I've been trying to get this KEXT/
CAPlayThrough combo working for quite some time now.
If you try and compile CAPlayThrough and do the same with the
AudioReflectorDriver and use them in tandem for 5 minutes (which is
what probably all developers who care about creating their own audio
device KEXT will do) you'll get glitches and distortion. IOW, what
good and useful is that KEXT project as a starting point if it
screws up your audio signal?
Again, thank you for all your help Jeff it is very much appreciated,
and if there's anything you can do to help us out just a little bit
further to get the AudioReflectorDriver working I'd be really,
really happy! ;-)
Thanks again,
Stephan
2009/1/9 Jeff Moore <email@hidden>:
> The AudioReflectorDriver wasn't ever meant to be used for anything
> important. It has some very definite limitations, especially when
the system
> gets busy (see the comments in the implementation of
AREngine::TimerFired()
> in the source for more info about that particular issue). Your
experience
> with it would clearly demonstrate this in fact.
>
> The AudioReflectorDriver's main job is to be sample code that
demonstrates
> the basics of writing an IOAudio-based driver. The fact that it is
also
> occasionally useful for testing purposes is a great side benefit. It
> certainly isn't expected to be bulletproof though.
>
> In this case, the AudioReflectorDriver was a useful point of
comparison
> since it does more or less the same thing that SoundFlower does but
> apparently doesn't exhibit the run-on problem that kicked this
thread off.
> My intent was to provide some a theory about what SoundFlower
might be
> doing differently. I certainly wasn't recommending one over the
other.
>
_______________________________________________
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
--
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