weirdness in render notify
weirdness in render notify
- Subject: weirdness in render notify
- From: John Clayton <email@hidden>
- Date: Wed, 29 Oct 2008 15:46:32 +0100
Hiya all,
Another day in the life of a newbie core audio guy (that's me, hoping
it aint you).
I've got a notify callback set on a matrix mixer that tries to detect
digital silence (by that I mean, complete zeroes across the board in
the inputs buffers). You'd imagine that it would be simple - and
perhaps thats why I'm really confused by this particular problem,
which is:
once my audio *stops* playing through the mixer my mixer notify
callback gets given the following data pattern:
(here I'm logging the first 10 bytes of each post-render callback on
the mixer)
C3 DB 4C 34 34 FC 49 34 5E F7
CA 6D 32 33 9C 69 07 33 45 3F
B8 8C 26 30 AB 15 9C B1 98 82
E3 89 11 31 7A 8E 21 31 1F 4C
53 D3 09 97 3D ED 08 97 AF 07
89 7E 6B 0D B7 02 67 0D FD 8D
00 00 00 80 00 00 00 80 00 00
00 00 00 80 00 00 00 80 00 00
00 00 00 80 00 00 00 80 00 00
00 00 00 80 00 00 00 80 00 00
00 00 00 80 00 00 00 80 00 00
00 00 00 80 00 00 00 80 00 00
you can see here very clearly the first 10 bytes of every single
render callback. Notice how it switches to a series of 00 00 00
80 ... , this happens at exactly the point when my upstream audio
finishes playing. The upstream audio provider then sets the
kAudioUnitRenderAction_OutputIsSilence on the
AudioUnitRenderActionFlags within its render method so I'd assumed
that this render flag would in turn be visible from within my
downstream lead-mixer callback (which it isn't - the code to detect
that never logs anything).
One other factoid:
- if I play NOTHING through the mixer, then its notify callback does
indeed detect that there is output silence (via the short-cut check at
the top of the callback).
seems very regular to me (and it also happens in the release build).
Does anyone know what could be causing this?
I've pasted the notification callback code below in case that helps, a
quick summary of its intent:
1 - reacts only on post-render
2 - it checks if the kAudioUnitRenderAction_OutputIsSilence flag is
set, if so this is used as a short-cut to determine that no audio is
present
3 - it does a brute force check along the entire buffer looking for
non-zero data, if that's found then we consider audio to be present
and thus we're done (i'm aware this could be made quicker, but am more
interested in getting it right first, and quick second).
OSStatus LeadMixCallback::notifyCallback(AudioUnitRenderActionFlags *
ioActionFlags,
constAudioTimeStamp * inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList * ioData) {
int flags = *ioActionFlags;
// we need data in the buffers, so only react on post-render
if((flags & kAudioUnitRenderAction_PostRender) == 0) {
return noErr;
}
// check if its all silence flag - I guess this is a shortcut so that
AU's dont have to bother filling in buffers?
if(flags & kAudioUnitRenderAction_OutputIsSilence) {
LOGGING_TRACE(logger, "the lead mixer thinks there is total silence");
_graph->leadAudioIsPresent(false);
return noErr;
}
bool foundSounds = false;
AudioBuffer* buf = ioData->mBuffers;
for(int bufIndex = 0; !foundSounds && bufIndex < ioData-
>mNumberBuffers; ++bufIndex, ++buf) {
if(buf->mData == 0)
continue;
UInt32 bytesPerFrame = buf->mNumberChannels * sizeof(Float32);
UInt32 totalBytesHere = bytesPerFrame * inNumberFrames;
unsigned char *buffer = (unsigned char*)buf->mData;
for(UInt32 count = 0; count < totalBytesHere; ++count) {
if(count < 10)
printf("X ", buffer[count]);
if(buffer[count] != 0 && count > 10) {
foundSounds = true;
break;
}
}
printf("\n");
}
_graph->leadAudioIsPresent(foundSounds);
return noErr;
}
Thanks
--
John Clayton
Skype: johncclayton
_______________________________________________
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