hi guys! feel free to state your opinions and experiences on this. I encountered a situation where several wav files needed to be played either simultaneously or on a given time and to start playing from a given position in the file. I implemented this before using DirectSound with threads monitoring each DSound buffer so that they would play at the right time. The threads were synchronizing on a global timer. It worked fine but as you add more wav files to the 'song', more threads would also need to be added. What happened was that delays during playing started to come up. The delay between the transition between one wav to another became evident. I also tried DirectMusic but it lacks so much in terms of using WAV files. It can't even seek into the WAV file using Segment->SetStartPoint() and following the instructions in the SDK about WAV files. Here's a summary of what I found out about the pros and cons of each of the API's: DirectSound: -can seek through the WAV file and start playing it from a chosen position within the file (with a little work, unfortunately). -no architecture available for song arrangement, etc. (ex. DirectMusic's performance/segments architecture) DirectMusic: -can load several WAVs together. Can play them 'simultaneously' through sequential calling of Performance->PlaySegment() but WAVs won't be played at exactly the same time. Reverb or echo results. -can't use most of the API calls on WAVs. -i think it's mainly used for MIDI files. DirectShow: -i don't have any experience on this yet but i tried its GraphEdit tool and it played several instances of the same wav file perfectly. no substantial reverb. -might be able to play several wav files with minimum delay between each one but it might not have anymore capabilities aside from playback. well, in short, what I need is an API that can arrange a timeline or schedule to play wav files starting from any given position in the file (think Sony's Acid Pro) without any problems, of course, like delays when playing starts. Thanks for any feedback!

thanks for the replies guys!

yup. DirectSound would be the first obvious choice but its lack of architecture left me with figuring out a design for my particular problem and currently they're all too slow. The second implementation I tried was to lessen the threads that monitor the buffers. Only one thread was tasked to watch the buffers and sync with the timer. Problem is it would need to call play on the buffers sequencially if they were to play at the same time. This solution lessens the burden of running more threads but loses the threads "concurrent execution" benefits. Well, concurrent is also sequential execution in a way because the CPU can only process one instruction at a time. Anyway, different implementation but same results. The delays were still there. I also think that the DSound->Play() method also has an overhead or latency that also contributes to this delay. So a much lower level solution might need to be used but we don't have time for that do we. hehe

You're right too about DirectShow. It might be able to do what I need after testing with GraphEdit and I think it can also seek through the file because of the TimeLine interface. Am I right about this?

If DirectShow is to be moved to the Platform SDK, then would it still be backward-compatible to older applications? And how would you redistribute it along with your software if it's not included in DirectX anymore?