Re: Driver seems a little dizzy while running more than onmediaplayer
Re: Driver seems a little dizzy while running more than onmediaplayer
- Subject: Re: Driver seems a little dizzy while running more than onmediaplayer
- From: Jeff Moore <email@hidden>
- Date: Fri, 27 Feb 2009 16:12:22 -0800
First off, let me say that I am most definitely not an expert on
FireWire. Because some of your problems may be specific to dealing
with FireWire, you may want to seek more help from our FireWire
experts which you can do through our Developer Support folks. This
email list may not be up to the task.
At any rate, The first problem I see with what you are doing is how
you are anchoring your time line. Basically, you are picking a random
point in time prior to starting the hardware and calling that your
zero point. Frankly, this is the worst way to do this because it has
no relationship to when the hardware really started. However, it is a
pretty common mistake that many driver writers have made regardless of
how their device is connected to the system. The easiest way to solve
this problem is to use your DMA program to do a small transfer, raise
an interrupt and then you can take your first time stamp since you
know exactly where the hardware is at that point.
It's hard for me to tell from your description, but what is the thread
context on which you are taking your time stamps? It sounds like it
might be a secondary interrupt, which is problematic for the reasons
I've already outlined.
One other job that I think you'll need to do is to have an independent
idea about how the FireWire clock relates to the CPU clock. This is
something that has to be factored into your calculations that are
producing time stamps. I'm also told that this is a pretty tricky job,
but I'm not really all that sure about what is involved. This would be
a good reason to seek advice from a source more knowledgeable about
FireWire.
On Feb 27, 2009, at 9:49 AM, David Tan wrote:
Hi Jeff,
You're always so lightening for me :)
I was referring to how your driver handles dropping time stamps for
the HAL. There are multiple real time threads running when there are
multiple user clients. If you are not careful with when you take
your
time stamp, this extra thread activity will introduce errors in your
time stamp by causing extra scheduling latency for the thread on
which
the time stamp is taken. The usual example of this is when a driver
takes it's time stamp in a secondary interrupt. The real time thread
activity will cause scheduling latency which introduces jitter into
such a driver's time stamp.
Sorry, I still have some confusion about the time stamp dropping.
As I understand, every client just transmits its audio data into
IOAudioFamily in an independent thread. Then IOAudioFamily will
layout audio
data from different client into the mixbuf of clipOutputSamples().
So every
time I see clipOutputSamples() being called, the data in its arguments
"const void *mixBuf" contains mixed audio.
Please see the algorithm of time stamp in my driver.
As it's a Firewire audio driver, there's an output DCL program which
keeps
sending audio data to device.
1. Before start the DCL program, I call clock_get_uptime() to record
the
beginning time.
fFirstTimeStamp = true;
clock_get_uptime(&fLastTimeStamp);
2. I maintain a counter (fWriteSamples) of the output buffer read by
output
DCL program. Every time DCL program output a sample, "fWriteSamples"
will
step by one. If fWriteSamples increases to the sample buffer size
which I
set initially (IOAudioEngine::setNumSampleFramesPerBuffer()), I will
call
clock_get_uptime() again to get the elapsed time since the last time
of
takeTimeStamp(). Then I input the current time to
IOAudioEngine::takeTimeStamp().
if ((fWriteSamples % kNumBufferSize) == 0)
{
IOAudioEngine::takeTimeStamp(!fFirstTimeStamp,
(AbsoluteTime*)&fLastTimeStamp);
clock_get_uptime(&fLastTimeStamp);
if (fFirstTimeStamp)
{
fFirstTimeStamp = false;
}
}
It works fine for only one client. For two clients, sometime it's
OK. But it
does get jitter sometimes. So there must be some errors. Could you
please
give me some advice or tips? Thanks a lot!
--
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