RE: [GD-Windows] Streaming WAVE audio

[Brian H. <bri...@py...>]

At 04:07 PM 4/27/2002 -0700, Jon Watte wrote:
>I suppose you mean CALLBACK_THREAD when you're actually using a
>thread.

Correct.

>Have you tried CALLBACK_EVENT and WaitForSingleObject as
>an alternative, btw?

Not yet, but I was hoping to avoid getting that desperate.

>Poor drivers?

This is an i815 board (my Win2K box), so I'm assuming that Intel's drivers 
don't suck that bad.

>Another thing to try is to use at least three buffers, possibly four,

I'm actually using three buffers right now, to no avail.  I fill and write 
them out when I start up to get the chain going, then when dealing with 
WOM_DONE I refill buffers that are WHDR_DONE and dispatch buffers that 
aren't (and which have presumably been filled previously).

>buffers powers of two in size, to work around some classes of bugs.

Did that, no difference.

>You also should not prepare a header more than once; prepare all the
>headers on start-up, then call waveOutWrite() in a cyclic fashion.

Yep, that's what I do.  They're all pointing to the same buffers through 
their lives:

GLOBAL char buffer[ 3 ][ 1024 ];

header[ 0 ].lpData = buffer[ 0 ];
header[ 0 ].dwLength = sizeof( buffer[ 0 ] );
waveOutPrepareHeader( ... );
//etc. etc.

>Another thing to look for is internal logic errors where you play
>the "wrong" buffer, and/or get out of sync if you miss one buffer.

That's what I'm thinking it is, but so far I don't see it.  It's probably a 
stupid bug on my part, unfortunately the tried-and-true "find the bug after 
sending an e-mail asking for help" trick didn't work this time =)

When processing WOM_DONE I do a bunch of sanity checks, including verifying 
that the buffer I'm writing is the next one that needs to be written; that 
the buffer I'm filling isn't INQUEUE; that the buffer I'm filling is 
DONE.  Should be pretty simple and straightforward.

>Last, you can poll the WHDR_DONE bit in the headers for the buffers,
>rather than relying on a callback to fill the buffers. This lets you
>use a model slightly closer to that of DirectSound.

Yes, I could do that, and I may once I get REAL desperate. I could poll the 
WHDR_DONE in a separate thread a la my DSound buffering version and go with 
that, but I have a feeling if I implement it that way that things won't 
actually get any better, I'll just have shifted around the problem.

Thanks!

Brian