thought I would post a follow-up to this somewhat old thread. I
think I have, at least, determined why I get a very short freeze when
I play a sound in a loop using PlaySound (or sndPlaySound).
Pre-loading didn't help because loading the data didn't take that
long, perhaps due to OS cashing, perhaps due to OS pre-loading the
resource, I don't know. Suffice it to say loading is pretty quick on
smaller resources (up to 11K or so).
Background: if the .WAV resource is very short, the sound playing is
SLOWER in the loop and generates a tiny pause in animation than it
would if the .WAV resource is much larger. Thinking a smaller .WAV
file would solve the problem, I reduced mine to 82 bytes, but it still
staggered, and did so more consistently.
Here's what I discovered, and it poses a potential easy fix for small
wav files being played in a loop (for example, if you wrote "pong",
this would solve your problem without having to use the more
complicated WaveOut() method). First my speculation about the cause.
My _speculation_ about this is that if the sound file is small and/or
doesn't take long to play in terms of time, the OS has time to open
the channel, play the sound, and close the channel. It is the process
of opening and closing the channel takes a significant amount of time
and causes the short temporary hang in processing, not the actual
loading and playing of the .WAV resource. This explains why the
WaveOut method solves the problem: you only open the channel once, do
all of your animation sound effects, and then close it. So there's
good evidence I'm right about this.
That being the case, if you're playing sounds in a timing-intensive
loop, add a
length of silence to the end of the .WAV file, so it will not have
time to complete before you call PlaySound() the next time.
Apparently, if sound calls are...I'll call them overlapped, the OS
works as if you're doing a WaveOut and doesn't close the channel to
play the next sound.
The drawback to this is dead weight in your EXE. If you only have a
few short sounds it would be a suitable fix, but not if you're playing
a lot of different sounds. There are other considerations that should
be fairly obvious which I won't point out here.
If you want to be clever, I noticed that silence is defined as nothing
more than contiguous bytes of x80 (hex) characters, at least in 8000Hz
files. So you could, in theory, store your tiny .WAV files in the EXE
as a resource, then at runtime stream each one into a new buffer and
concatenate a block of 128 (ASCII) bytes to the end of the stream,
ending with a NULL for EOF. However, that may be as much work as just
using WaveOut :>)
In closing, I also found what looks like a good article by Fabricio
Kury from May 14, 2003 at
http://www.pocketpcdn.com/articles/multiplewaves.html. He gives a
pretty simple description of how to use WaveOut and includes a sample
class that allows you to pass a .WAV file name to the class
constructor and it plays the sound for you, similar to how PlaySound
works. Looks like it might be simple to replace the file loading with
Hopefully this will help the next newbie with this issue.
"patrox" < XXXX@XXXXX.COM > wrote in message news:<40b634f9$0$315$ XXXX@XXXXX.COM >...