Re: Stopping a Audio Unit From Callback PROPERLY
Re: Stopping a Audio Unit From Callback PROPERLY
- Subject: Re: Stopping a Audio Unit From Callback PROPERLY
- From: Brian Barnes <email@hidden>
- Date: Mon, 1 Oct 2001 02:07:48 -0400
On Monday, October 1, 2001, at 01:16 AM, andybull wrote:
Maybe (as is often the case) I am misunderstanding the question but it
is my
understanding that you should never ever stop an audio unit from within
the
component itself. You should simply fill the buffer with zeros. This
would
be because the component maybe linked (connected) into some realtime
engine
that requires the system to be runnning all the time. You should only
call
stop (or start) from code that is external to the audio unit. ie the app
that owns the audio graph. (??)
I'm using only audio units, they aren't owned by an audio graph.
Calling stop from within the callback doesn't work, so that's not even a
path to follow for me.
Think of it like this: I have X audio units. Each one is a "spot" for
a sound in the game. You are playing 5 concurrent sounds, each has it's
own audio unit. Now, if there are say 8 audio units, I want the others
to be in the stopped position, because then they take up no processing
time. 3 audio units (with a very quick fill callback) take up about
2.7-3.6% of the processor time. So, if I play a one-shot sound in an
audio unit, when I notice I reached the end of the buffer, I fill the
rest of the buffer with 0s, and throw up a flag. On the next callback,
I immediately error out. This *seems* to put the unit in the stopped
state, and it's ready to get a new sound if needed.
Until I'm told different, I'll keep doing this. I haven't heard any
static or other problems.
I assume, for games, people will want to do one-shot audio-units a lot,
unless they are implementing their own mixers and using one unit.
[>] Brian