Jump to content
  • Advertisement
Sign in to follow this  
bjut

DirectShow or DirectMusic or DirectSound?

This topic is 4892 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
Well I would forget DirectShow because it has now been removed from the SDK. I would go with DirectSound.

Share this post


Link to post
Share on other sites
I think you are correct with DirectMusic, it seems mostly geared towards MIDI. I would say go with DirectShow. You have already prototyped with GraphEdit, so you know it will work and the performance is good. Also, you can get access to the DirectSound secondary buffer by querying the DirectSound Filter in your graph if you need to do anything low level.
Quote:
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.

This is probably a lot like what DirectShow is doing for you, but it is likely to be more optimized than your own code. No sense reinventing the wheel right? :)

Quote:
Well I would forget DirectShow because it has now been removed from the SDK.

DirectShow is not included with the SDK any more because it is being migrated away from DirectX and into the Platform SDK. It is in no way dead. I think that the developers want DirectX to move towards strictly being a library for games that works across several platforms, and DirectShow has a little trouble fitting in in that context. You can still get DirectShow as part of the DirectX 9.0 February Extras Package, and in the near future you should see it bundled with the Platform SDK.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!