Re: Curious happening with CAPlayThough
Re: Curious happening with CAPlayThough
- Subject: Re: Curious happening with CAPlayThough
- From: Jeff Moore <email@hidden>
- Date: Thu, 08 Jan 2009 23:36:00 -0800
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.
On Jan 8, 2009, at 10:12 PM, Stephan M. Bernsee wrote:
Hi Jeff,
we would gladly use the AudioReflectorDriver instead of Soundflower,
but that one has another curious problem with CAPlayThrough: after
about 5 minutes of playthrough operation it starts glitching like
hell (problem #1 in my last message - but worse than Soundflower and
more frequently). At first I thought that had something to do with
the input and output sample rates not matching up (and they are in
fact slightly different and fluctuating), but that's what
CAPlayThrough's AUVarispeed unit is supposed to be there for, right?
Btw. it looks like the AUVarispeed's rate is set with numerator and
denominator reversed (line 642 in CAPlayThrough.cpp). But even after
correcting this it still doesn't work... I'd appreciate any help
that you can give us to solve these problems!
Thanks!
Stephan
2009/1/9 Jeff Moore <email@hidden>:
> That's interesting information. When I have seen drivers have a
run on
> problem, it was usually caused by the driver not doing enough
management of
> the erase head. Because the IOAudio family will continue to play
for a full
> ring buffer's worth of time after being told to stop, any erase head
> problems will manifest kind of like this. It happens like this
especially
> with short sounds as the quick start/stop sequence can exacerbate
any
> existing problems.
>
> The primary means to control the erase head is the IOAudioEngine
method,
> getCurrentSampleFrame(). This method is supposed to return where
in the ring
> buffer the driver is currently, but it doesn't have to be an exact
or
> perfect figure (although it should be reasonably close). In fact
in the
> AudioReflectorDriver, this method just returns the current
position with a
> granularity of 512 sample frames. This allows the erase head to
keep up, but
> not overwhelm the driver.
>
> At any rate, one theory I have is that SoundFlower is keeping the
erase head
> running very far behind it's current position. So if you have a
sound that
> starts and stops quickly, then perhaps the erase head is never
getting a
> chance to run. So when IOAudio runs through the buffer the last
time, the
> old data hasn't been erased yet and you hear it again. Just a
theory, but it
> might provide some guidance on where to look in the SoundFlower
code to fix
> the problem.
>
> BTW, if you have already found it, the AudioReflectorDriver code
is in our
> SDK in the directory, /Developer/Examples/CoreAudio/HAL
>
>
--
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