Re: mRateScalar, audio driver speed
Re: mRateScalar, audio driver speed
- Subject: Re: mRateScalar, audio driver speed
- From: Bill Stewart <email@hidden>
- Date: Thu, 15 May 2003 18:59:17 -0700
On Thursday, May 15, 2003, at 06:32 PM, email@hidden wrote:
Hi!
I asked a while ago a few questions about getting post mix audio, and
Laurent suggested taking a look at the PhantomAudioDriver example,
which
turned out to be just the ticket; I modified that slightly so i could
get
my post mix audio output coming right back in as input. So that's all
well and good, but:
I wanted to be able to hear the audio also, so I wrote a little app
that
plays the Phantom input out through the Built-In output. It soon
became
clear that the phantom input was providing data ever so slightly slower
than the Built-In output wanted it. I converted the sample rate just a
bit using apple's AudioConverter code, and that works ok, but it
doesn't
seem like the right solution. Is there any way to ensure that the
drivers
run at the same speed (or at least, much closer)? I am seeing a
difference of about 0.5%, which is consistent with the mRateScalar,
which
usually stays around 0.995 for the Phantom driver and 0.9999 for the
Buit-In driver.
Correct - hardware doesn't ever run at the nominal sample rate - thus,
the rate scalar...
And the approach you are doing is basically correct - to adjust for
different rates of playback you need to tweak the rate of the audio so
that it stays in sync...
So - you are constantly adjusting the rate based on the relationship
between the two rate scalars (in your case the relationship between the
builtin hardware and your driver)
Nothing I'm doing seems time consuming, so i don't think I could be
overloading anything; the driver is simply copying the data and
clipping
it, and the playthrough app's ioProc was seeing the 0.995 mRateScalar
even
when there was no code in the ioProc (other than to note the
mRateScalar,
of course)
So, is this to be expected? Is there some way to slave the two
devices,
or at least make the phantom driver more accurate? It seems like the
capability is there for more accuracy, since the system knows exactly
how
far wrong the driver is...
Thus - word clock - this synchronises different pieces of audio
hardware to keep their A-D-A converters synchronised, and in that case
the different pieces of hardware run at the same actual rate...
It is because we do know more about what the hardware is doing that we
can tell you the rate scalar - which describes the difference between
the nominal sample rate (44100) and the actual sample rate of the
hardware (44100 * theRateScalar)
I've probably said something above that indicates my lack of
understanding, so if I'm asking the wrong questions please let me know!
Actually you are asking the same questions I've been asking of late!,
and you've taken the correct steps to solve it...
Bill
thanks for any help or tips!!
-jg
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.