I play an MP3 sound using the following mciSendString
mciSendString("play \"mysound.mp3\"", NULL, 0, 0);
The above works just fine. But from what I've seen around the web, people use all kinds of wrappers for the above code. Some first send open
command then play
, then wait for notification, then send close
command, they also use aliases for files etc.
My question is - is all this necessary? My primary interest is just to play a file and do it in async manner. The above command appears to do all the cleanup so my question is - is it really required to use open
or close
command and notifications when the sound has been played to properly release memory and deallocate sound and is there an advantage to doing so.
From what I can see in the debugger it appears that on execution of above command the system loads required DLLs, then starts some threads and as soon as the playback ends, the threads exit and the DLLs are unloaded. So my guess is that open/close are optional because the system does all the allocation/deallocation automatically, but I may be wrong. Am I leaking some memory or resources if I just call the above line and nothing else?
Here is what the debug log shows - all I can conclude from this log that the thread is closed and that the the DLL files are unloaded:
Module Load: MCIQTZ32.dll. No Debug Info. Base Address: $61D80000. Process Project1.exe (368)
Thread Start: Thread ID: 492. Process Project1.exe (368)
Module Load: SETUPAPI.dll. No Debug Info. Base Address: $77920000. Process Project1.exe (368)
Module Unload: SETUPAPI.dll. Process Project1.exe (368)
Thread Start: Thread ID: 1344. Process Project1.exe (368)
Thread Start: Thread ID: 640. Process Project1.exe (368)
Thread Exit: Thread ID: 1344. Process Project1.exe (368)
Thread Exit: Thread ID: 640. Process Project1.exe (368)
Thread Start: Thread ID: 468. Process Project1.exe (368)
Thread Start: Thread ID: 1120. Process Project1.exe (368)
Module Load: SETUPAPI.dll. No Debug Info. Base Address: $77920000. Process Project1.exe (368)
Module Unload: SETUPAPI.dll. Process Project1.exe (368)
Thread Start: Thread ID: 1692. Process Project1.exe (368)
Thread Start: Thread ID: 1384. Process Project1.exe (368)
Thread Start: Thread ID: 204. Process Project1.exe (368)
Thread Start: Thread ID: 1572. Process Project1.exe (368)
Thread Exit: Thread ID: 1692. Process Project1.exe (368)
Thread Exit: Thread ID: 1384. Process Project1.exe (368)
Thread Exit: Thread ID: 1572. Process Project1.exe (368)
Thread Exit: Thread ID: 204. Process Project1.exe (368)
Thread Exit: Thread ID: 1120. Process Project1.exe (368)
Thread Exit: Thread ID: 468. Process Project1.exe (368)
Module Unload: MCIQTZ32.dll. Process Project1.exe (368)
Thread Exit: Thread ID: 492. Process Project1.exe (368)
I found the answer elsewhere so I'm sharing it.
It appears that the
play
command by itself is perfectly valid.So here are a couple of ways to call this:
Answer found on MSDN Forums.
Once important thing worth noting is that
mciSendString
will fail miserably if you supply it with filename with spaces in the path (e.g. C:\Program Files...). Even if you enclose this into quotes it won't help. The solution is to useGetShortPathName
Windows function to get a DOS-like path from NTFS path name and which doesn't have spaces in it.