Re: Welcome to the "Coreaudio-api" mailing list
Re: Welcome to the "Coreaudio-api" mailing list
- Subject: Re: Welcome to the "Coreaudio-api" mailing list
- From: Jeff Moore <email@hidden>
- Date: Tue, 9 May 2006 17:11:35 -0700
On May 9, 2006, at 4:21 PM, Gen Kiyooka wrote:
New to CoreAudio/KEXT, but a fan in general (aside from my Mbox
driver, that is),
I was checking out AudioReflectorDriver in combination with
ComplexPlayThru.
Using the list archive, I have been able to rebuild
AudioReflectorDriver with the flags to allow me to set the system
prefs to send regular audio output through the driver.
My first test was to install the driver system wide, run
ComplexPlayThru, and simply do all my normal audio listening through
that combo. It seems to work pretty good, but there is a periodic
warbling/distortion that appears, no matter what audio client I use.
I tried iTunes/VLC/QuickTime player pro/Finder preview - all exhibit
the same behavior.
Initially, I thought it might be a drm/audio watermarking thing, but
it seems that regardless as to the source of the audio, the same
results. I am building/testing on Intel.
I take it that you are using an app to send data to the Reflector and
then using the ComplexPlayThru to send the data from the reflector to
some real piece of hardware. Presuming that is correct, you have a
problem in that the two devices are not synchronized. As such, they
will drift relative to each other and you will get glitches.
That said, can you clarify/quantify "a periodic warbling/distortion"
a bit? Warbling sounds like the distortion is changing frequency
content which isn't the sort of problem I'd expect with the set up
you've described. Mostly you get dropped samples or repeated samples
when two devices set up like this drift apart. This would sound like
periodic pops or clicks or, in extreme cases, whole segments getting
repeated.
On a related thought, can someone tell me exactly what parts (strings
etc) of AudioReflectorDriver need to be changed in order to clone the
driver without overlapping any of the namespace of the original
sample. I started on this project as well, and it worked, ah, once,
and then my cloned driver disappeared and/or caused a kernel panic on
boot.
You need to change all sorts of class names and bundle identifiers
and what not. I very much recommend that you learn a bit about
general IOKit development before you proceed. The docs included with
the system have been very helpful for me over the years.
I'd also go download a copy of the kernel and IOAudio family sources
so you can see basically what's going on in the layers around you in
the kernel. Note that these sources are almost certainly not what's
shipping, but it's close enough to get a good feel for what's going on.
Final question. For building a universal KEXT, is it any different
than a regular universal binary? The "Release" build for
AudioReflectorDriver uses $(NATIVE) rather than "ppc i386"
The project always builds for the native architecture. Typically, we
do shipping builds from the command line and set the architecture
flags there.
At any rate, things are generally the same between Intel and PPC. The
big difference is that the IOAudio Family headers on PPC systems
can't build a driver that can be loaded on Intel systems due to
changes in the Family to support Intel. What you need to do is one of
the following:
- Do your builds for both architectures on Intel hardware using the
set of headers on the system.
- If you want to build for both architectures on PPC hardware, you
need to replace your IOAudio headers with those that came with the
Intel system.
--
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