Re: Curious happening with CAPlayThough
Re: Curious happening with CAPlayThough
- Subject: Re: Curious happening with CAPlayThough
- From: "Stephan M. Bernsee" <email@hidden>
- Date: Fri, 9 Jan 2009 19:00:27 +0100
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