And now, at least as a step toward managing my audio in a persistent thread,
worker thread's function. So I am running two audio threads with no
apparent problems. If someone tells me I can't do it this way, I will at
least be in a much better position to do it differently.
That's very helpful, Scott. Between our posts, I had tried tried a while
loop with SuspendThread. For my simple waveOut, it seems to be working
just fine. Is there anything fundamentally wrong with this approach?
Mainly, I am trying to get a firm grasp on such use of a thread. Also, if
you get the time, would you mind demonstrating a version that relies on
messaging? I want to be sure to get what you're saying about that, and
these examples together might just be the best way for me to see the
picture most clearly. Thanks again!
// audio thread function
UINT AudioThreadFunc(LPVOID pParam)
{
while(TRUE)
{
CAudioFile* audiofile = (CAudioFile*)pParam;
if(WaitForSingleObject(audiofile->m_hndDone,INFINITE) !=
WAIT_OBJECT_0)
{
// error handling code goes here
return 0;
}
CloseHandle(audiofile->m_hndDone);
if(audiofile->m_pView->m_hWnd)
audiofile->m_pView->PostMessage(WM_AUDIO_CLEANUP);
else
audiofile->CleanUp();
::SuspendThread(audiofile->m_pAudioThread->m_hThread);
}
return 0;
}
----------------------
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:uC8fsvbvGHA.1808@TK2MSFTNGP06.phx.gbl...
Steve Russell wrote:
// 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?
To keep the thread alive for the life of the app the thread is going to
be started one time only and consist of a "do forever" loop.
You don't "call" a thread, you signal to it. You can use a worker thread
or a message-driven thread. For the worker thread case like you have now
the new thread function would look about like this...
UINT AudioCallback(LPVOID param)
{ CSomeClass* p = (CSomeClass*)param;
while(TRUE)
{ DWORD signal = WaitForMultipleObjects(
p->hcount, p->handles, FALSE, INFINITE);
switch(signal)
{ case ... break;
case ... break;
}
}
return 0;
}
While no event is signaled the thread is suspended in
WaitForMultipleObjects. You signal to the thread using SetEvent, which
causes one of the case statements to execute. The first case should be a
shutdown command that makes the thread exit during app shutdown.
A message-driven thread is better in many cases, but since you already
have a worker thread I guessed you probably want to try this approach.
I suggest you change the name of the thread function - callback is
misleading.
--
Scott McPhillips [VC++ MVP]