• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Stopping a Audio Unit From Callback PROPERLY
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stopping a Audio Unit From Callback PROPERLY


  • Subject: Re: Stopping a Audio Unit From Callback PROPERLY
  • From: Bill Stewart <email@hidden>
  • Date: Tue, 2 Oct 2001 12:28:31 -0700

On Monday, October 1, 2001, at 10:35 PM, Brian Barnes wrote:
Chris Rogers wrote:

Ordinary AudioUnits do NOT have any concept of being started or stopped.
Only output AudioUnits (kAudioUnitSubType_Output) understand
AudioOutputUnitStart() and
AudioOutputUnitStop(). AudioOutputUnitStart() starts the hardware device
associated with the AudioUnit. AudioOutputUnitStop() stops the hardware
device from calling back through the HAL. Our stereo mixer AudioUnit
(kAudioUnitSubType_Mixer, kAudioUnitID_StereoMixer) allows for connections
to be made and broken to the input busses. You can dynamically allocate
one-shot sounds to mixer inputs, and when the sound is finished, simply
disconnect the input, and you'll get no more callbacks for that input.
Other connected inputs to the mixer will continue to callback, however.

OK, I get this. So what would be the recommendation for something like a game? Multiple audio units or a single stereo mixer audio unit with multiple inputs?

Personally I'd use the mixer and just connect and disconnect your sources.

(As a point of information from your previous methodology:
If you're input callback wanted to be kept live but intermittently generated sound or not, the best way to deal with this would be to have a state variable that your callback uses to determine if it should produce sound or not... then all you do is:
if (!makeSound)
return noErr;

The supplied buffer is already zeroed, so this won't corrupt your signal chain - you just end up giving zeroes back... but this *still* might mean that work is done down chain and you'll still get called for new buffers.

Returning an error code is *not* a recommended way to disconnect your input source - use the Disconnect APIs...)

Multiple audio units (which I'm doing now) seem to work fast enough, and take very little processor time. I do this because it seems very close to the idea of multiple channels in the sound manager, which is where I came from.

Also, a side question: Can the subtype_effect units take multiple inputs? Or would I have to mix all my audio units in a mixer audio unit, send that to the effect, and then send that to an output unit? If so, that would be a good reason to go with a single mixer unit!

Nope - you'd need to mix the input to the format the effect can take - think of an ALT bus on a hardware mixer and you'll get the idea

Bill


[>] Brian
_______________________________________________
coreaudio-api mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/coreaudio-api


mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
Cat: "Leave me alone, I'm trying to nap... Ah, What's that clicking noise?"
__________________________________________________________________________


  • Follow-Ups:
    • The Audio Units Sample Code
      • From: Brian Barnes <email@hidden>
References: 
 >Re: Stopping a Audio Unit From Callback PROPERLY (From: Brian Barnes <email@hidden>)

  • Prev by Date: Re: Location of IOAudioDevice.h and other I/O Kit Headers
  • Next by Date: Re: Oops! Digest messed me up
  • Previous by thread: Re: Stopping a Audio Unit From Callback PROPERLY
  • Next by thread: The Audio Units Sample Code
  • Index(es):
    • Date
    • Thread