Re: weirdness in render notify
Re: weirdness in render notify
- Subject: Re: weirdness in render notify
- From: John Clayton <email@hidden>
- Date: Wed, 29 Oct 2008 15:52:01 +0100
Update:
Duh.
Buffers are Float32 not char, so checking for zeroes across the entire
buffer is never going to work if the float values are set to -0 for
example - right?
Thanks
--
John Clayton
Skype: johncclayton
On 29/10/2008, at 3:46 PM, John Clayton wrote:
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
_______________________________________________
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