Re: weird question: mixer callbacks and buzzsaws.
Re: weird question: mixer callbacks and buzzsaws.
- Subject: Re: weird question: mixer callbacks and buzzsaws.
- From: William Stewart <email@hidden>
- Date: Wed, 29 Oct 2008 11:25:07 -0700
On Oct 29, 2008, at 2:33 AM, John Clayton wrote:
Ah, excellent description - thank you Bill. The makes sense given
the parameters to each of the calls as well. At this point, I take
my hat off to the list for providing me solutions overnight where I
might otherwise have floundered for days.
Another question too: silence (no audio) is determined by either a
buffer full of zeroes, or a flag in the AudioUnitRenderActionFlags
flags passed to a render or notify callback function. Is that
assumption true?
you can't just rely on the silence bit.
The audio data must always be correct. The silence bit can certainly
be used - this can be used by the au as a hint, but the data itself
still has to be silent
Thanks
--
John Clayton
Skype: johncclayton
On 28/10/2008, at 9:03 PM, William Stewart wrote:
These two things are quite different:
The input/render callback is a struct that is attached to an input
scope and an element (bus) on that scope (AudioUnitSetProperty as
below). Its role is to provide audio data for that input. The
buffer that you are given in the input callback should be modified
to contain the audio data you wish to provide for that input. If
you have no audio data to provide at any time this is called, you
should fill it with silence (memset each/every buffer data to zero)
The render notification is a callback that is called on the output
side of an audio unit - AudioUnitAdd/Remove RenderNotify(WithProc).
It is called both before an output is rendered and after it has
completed. If an audio unit has more than one output it is called
for each output bus when that output bus is called to render. In
the pre case, the audio buffer list's audio data contents are
undefined. In the post case, the audio buffer list's audio buffer
data contents contain the results of the unit's audio render
operation on that output bus. With Leopard we deprecated the
original version of this call and redefined the add and remove to
both take the callback and client data pointer. Please use that one
if possible.
Bill
On Oct 28, 2008, at 2:05 AM, John Clayton wrote:
oops, sorry to be not specific enough. I'm doing this:
XThrowIfError(AudioUnitSetProperty(_audioUnit,
kAudioUnitProperty_SetRenderCallback,
_scope,
_bus,
&input,
sizeof(input)), "setting render callback on unit");
have I confused the notify callback, with a render-callback which
*must* do something?
<hiatus>
correct. I believe I did confuse this. I used Peters idea of the
notification callback as opposed to the render-input callback -
and now I don't (so far) get any terrible screeching. One more
thing to throw into my little knowledge-bag there...
Peter also has a point with the docs, I didn't spot that one -
although I too know in the back of my head that there is a
difference between the input and the notify, and like Peter swear
I've seen that written down somewhere.
Is the notify always called post-render?
Thanks
--
John Clayton
Skype: johncclayton
On 28/10/2008, at 3:55 AM, William Stewart wrote:
On Oct 27, 2008, at 2:53 PM, Peter Rebholz wrote:
On Oct 27, 2008, at 4:34 PM, William Stewart wrote:
umm - the doing of nothing is not an option.
In the callback you are given a buffer list of audio buffers to
fill in - the buffer is not zero'd (saves CPU time), so at the
very least you will have to do a memset to 0 of the buffer
contents.
This is what I thought initially but then I reread the message.
I think he's referring to AudioUnitAddRenderNotify. Which, if I
recall correctly, doesn't require you to do any work as it is
simply notifying you of the result of the render call.
yes, but he said his input callback - and this does require that
I don't know what's going on but I can't seem to find any
documentation for that function. It's not in the XCode
documentation tool (I recently updated the doc set) and the
header doesn't have anything, so I apologize if I'm wrong. I
could have sworn it was there at some point because how would I
know what it was otherwise?
Peter
_______________________________________________
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
_______________________________________________
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