Post by DMSThanks. I am concered about timing issues, and my application is
already pretty complex. It recieves TCPIP messages over a network and
some of these messages are requests to play certain sound files. I
would like to havethe option of also having these messages request
that the sound file loops. So I cannot predict which sound files will
be used nor when the requests will come in. If I loop a sound I need
to be able to provide an alias so that it can also be stopped by a
later request. In addition to incoming requests, my app is also firing
the playing of hundreds of very small sound files.
Hundreds ? The soundcard itself will be limited in how many simultaneous
sounds it can play without using a pre-mixer of some sort (based upon
the number of hardware and software buffers).
MCI handles mixing for you but is still limited by the hardware/driver
support which can both vary widely and report it's capabilities
incorrectly (for instance Creative Audigy cards report their max
hardware buffers but do not report unused buffers [returning max
buffers] as the driver recycles them itself internally).
Post by DMSI have seen some code that subclasses the windows messages etc to get
a call back when the sound has finished playing, so that one can play
it again. That is somewhat similar to what I have done in thepast with
the MCI player control but I worry that there will be a gap betwwen
the sound iterations if my code is already very busy.
With MCI there are 2 options;
Subclass the MM_MCINOTIFY message that is called whenever a sound (that
was played via MCI with the notify flag set) ends
Use an individual timer (not a good idea) or timer manager to call loop
logic whenever a sound is expected to end
Either method might have problems with lots of sounds, I've only used
both with 8-12 sounds.
Method: Subclassing
When the MM_MCINOTIFY message is sent you to use some logic, typically a
loop, to check the status of all playing sounds to see if they have
ended. If you have lots of sounds, particularly if some end at the same
time, you may miss some as their status hits end after you have checked
it.
Method: Timer Manager
You create a linked list by time to play (derived from checking play
length on load), you run a single multimedia timer (due to it's higher
precision over standard timers) and check the linked list on timer
events to see if any sounds are expected to have ended at that point
(you can also them use a limited status check of only those sounds
expected to have finished to see if they have actually finished).
Depending upon your timer increment you may miss some.
-
The timer manager method can probably handle more sounds at once as it
either doesn't have to check all playing sounds or can ignore checking
sounds that are expected to have finished based upon timing (although
this itself may cause artifacts if sounds did not quite finish or the
timing is not tight enough).
Either method is going to have trouble if your code is doing a lot of
other work as well though. Both methods may cause problems if they steal
focus from your main 'thread'.
Post by DMSI suspect I should simply back off the Windows limitation of not
allowing loops with .wav files and only support looping with mp3
files.. :-(
Method 3:That would be another option, and might actually be the better
option for your app from what you've said. You let MCI handle the
looping and you can still stop sounds as you like from elsewhere. I
think the overhead of either a message or timer handler might cause more
problems than issues it resolves if you're handling hundreds of sounds.
The only other option is DirectSound, which let's you ignore some of the
hardware limitations, but it's really going to end up using similar
methods.
I'll try to trim out some basic samples of each method (excluding
DirectSound) but I'm not sure how they'll scale as I've not used them
for large amounts of sounds before.
--
Alfie [UK]
<http://www.delphia.co.uk/>
Youth is wasted upon the young...all that energy and no experience :).