Tripped up and dead with Disconnect() then Connect()
Tripped up and dead with Disconnect() then Connect()
- Subject: Tripped up and dead with Disconnect() then Connect()
- From: Lance Drake <email@hidden>
- Date: Sat, 5 Jun 2004 01:58:39 -0600
Can anyone expand my mental horizons with a notion as to what might be
the problem with sending a 'Disconnect()' call and then promptly send a
'Connect()' call as might be the case with the AudioFilePlayer sample
code?
There is a pragma that says "#warning This should redirect the calling
of notification code to some other thread" that's located next to the
"void AudioFilePlayer::DoNotification (OSStatus inStatus) const"
function. Unfortunately, I am not sure what to do about this -
although I know this is evidently something important as this is the
call where my code dies if I decide to generate audio from one file and
then move to another file.
It seems there is some bookkeeping and extrication from the audio
thread that has to take place because the crash is time-dependent. If
I wait a second between requesting Disconnect() and then calling
Connect(), there's no problem. Only when I call Disconnect() and them
promptly call Connect() does the app crash in DoNotification due to a
bad exec access via "AudioFilePlayer* THIS =
const_cast<AudioFilePlayer*>(this);".
Thus, what I would like to know is:
1) "How do I programatically determine the coast is clear enough to
issue a Connect() call?". (Simply inserting a delay seems such a
pitiful solution.)
2) "What is meant by 'redirect the calling of notification code to some
other thread'?".
I would be so happy to RTFM if anyone would suggest what is that manual.
Thanks!
Lance Drake
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.