Re: returning from worker thread
I find myself puzzled as to how to leave the worker thread alive. In a
function that I call AudioWaveOut, I had been including this:
. . .
if(m_pAudioThread)
{
delete m_pAudioThread;
m_pAudioThread = NULL;
}
m_pAudioThread = AfxBeginThread(AudioCallback, this, 0, 0,
CREATE_SUSPENDED);
m_pAudioThread->m_bAutoDelete = false;
m_pAudioThread->ResumeThread();
. . .
if(waveOutWrite(m_hWaveOut, m_WaveHdr, sizeof(WAVEHDR)))
. . .
Now, in an attempt to implement what you are saying, I am trying this:
. . .
// first call for thread
if(!m_pAudioThread)
{
m_pAudioThread = AfxBeginThread(AudioCallback, this, 0, 0,
CREATE_SUSPENDED);
m_pAudioThread->m_bAutoDelete = false;
m_pAudioThread->ResumeThread();
}
. . .
if(waveOutWrite(m_hWaveOut, m_WaveHdr, sizeof(WAVEHDR)))
. . .
How do I make subsequent calls to the worker thread's function, i.e.
AudioCallback?
----------------
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:edc2zSOvGHA.5056@TK2MSFTNGP06.phx.gbl...
Steve Russell wrote:
Let me stick with one specific example for now: A 2-second audio clip is
playing. The student quickly drags and drops a sprite before the audio
is finished playing. The underlying code for that operation performs
many functions, including setting a timer to check that the audio has
concluded before going on with further considerations that include audio
cleanup and beginning the next loop.
1 audio != 1 thread
If you have tightly linked playing one audio clip with creating and
shutting down one thread then you have unnecessary complexity, which
sounds like overhead that's getting in your way. Imagine an audio thread
that exists for the lifetime of the app. When you want it to play
something you post it a message telling it what to do. Then you forget
about it. Or, if you really need to know if/when the clip has finished
the thread posts a message to you when that happens. But the thread
remains ready, waiting for the next command message.
--
Scott McPhillips [VC++ MVP]