Re: Timing problem on PPC based Macs (PortAudio)
Re: Timing problem on PPC based Macs (PortAudio)
- Subject: Re: Timing problem on PPC based Macs (PortAudio)
- From: Jeff Moore <email@hidden>
- Date: Fri, 20 Mar 2009 14:54:19 -0700
What you are seeing is both normal and expected. It might surprise you
to learn that pretty much no audio device ever runs at it's stated
nominal sample rate. They all run a little faster or a little slower.
Further, this rate will drift over time, so a device might start out
running a little slow but as it's circuits heat up over time, it might
run a little fast.
This means any time you are trying to synchronize operations across
multiple devices or multiple machines, you really have to account for
the clock drift. It is definitely significant and will be noticed
given enough time.
Since you are doing things over the network, you have the added burden
of coming up with an objective timebase that you can use to relate the
time bases on the different machines. The reason why is that even if
you have two identical machines, their internal clocks will never be
running at precisely the same rate. Hence, you need to account for the
drift by using a third time base.
On Mar 20, 2009, at 2:39 PM, Thomas Tempelmann wrote:
On Fri, Mar 20, 2009 at 18:00, Thomas Tempelmann
<email@hidden> wrote:
When I play any sound on a PowerPC based Mac, the Mac's time and the
time the audio engine report do slowly drift apart. About one ms per
second.
I've gotten further debugging this:
1. I made a mistake giving the amout of the drift: It's 100ns per
second, not 1000ns per second.
2. I have sorted out PortAudio's involvement in this: I play now an
audio stream and get these two parameters:
- Microseconds()
- AudioDeviceGetCurrentTime()'s mSampleTime
When comparing these over time, I see that every second the only 47996
to 47997 samples get played on PPC, while it's the full amount (44100)
on Intel CPUs. (native sample rate is 48000 on PPC and 44100 on
Intel).
And this lack of 3-4 samples per second accumulates over time, it's
not a measurement error: after ten seconds, about 35 samples are
missing, and so on.
Can someone shed some light on this?
Is that "normal"? Can it be adjusted somehow?
And before you ask: "Why do you care, you can't hear the
difference"...
I was actually searching for problem in my app where I experienced a
much bigger drift: I send audio data over the network (LAN, low
latency) from one Mac to another, and I saw a rather noticable drift
over a minute or a few (in the range of 1ms/s).
When I then noticed this timing problem I described here, I first
thought that this is the cause for the big drift. But this drift of
100ns/s is rather small compared to the drift over the network. Maybe
the Microseconds between my Intel and my PPC Mac are not in sync at
all, causing a drift of 1ms/s? Could that be?
Wow, and I thought it would be easy to "just" transfer some sound from
one Mac to another over TCP.
--
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