Re: How to detect what is happening when using CALLBACK_EVENT rather than CALLBACK_WINDOW
- From: "Chris P. [MVP]" <msdn@xxxxxxxxxxxx>
- Date: Mon, 18 Apr 2005 12:37:08 -0400
On Sun, 17 Apr 2005 18:24:12 +0100, Angus Comber wrote:
> Thanks.
>
> I want to stick with CALLBACK_EVENT.
>
> You say: It takes more communication from the rest of your app to know what
> is going on. What communication do you mean?
Communication, in that, your app has to notify your callback hander thread
if you go to stop mode so that you don't attempt to queue any more buffers.
> I have worked out I can do this:
> if (m_pWaveHdr2->dwFlags & WHDR_PREPARED) // to check if WAVEHDR prepared
>
> and:
> if (m_pWaveHdr2->dwFlags & WHDR_DONE) // to check if buffer used up
Those are the only flags you need to deal with, buffers that are currently
queued to play will have WHDR_INQUEUE. When re-queuing a buffer that is
done, you can simply reset the flag value to WHDR_PREPARED, adjust the
dwBufferLength if necessary and call waveOutWrite().
.
- References:
- How to detect what is happening when using CALLBACK_EVENT rather than CALLBACK_WINDOW
- From: Angus Comber
- Re: How to detect what is happening when using CALLBACK_EVENT rather than CALLBACK_WINDOW
- From: Chris P. [MVP]
- Re: How to detect what is happening when using CALLBACK_EVENT rather than CALLBACK_WINDOW
- From: Angus Comber
- How to detect what is happening when using CALLBACK_EVENT rather than CALLBACK_WINDOW
- Prev by Date: MIXER sample
- Next by Date: Re: Voice Recording delay when using Codec
- Previous by thread: Re: How to detect what is happening when using CALLBACK_EVENT rather than CALLBACK_WINDOW
- Next by thread: What does silence look like
- Index(es):
Relevant Pages
|
