Strange bug with a Ruby MCISendString wrapper.

Started by ForeverZer0, April 27, 2012, 11:55:21 pm

Previous topic - Next topic

ForeverZer0

I know this is more of a a general Ruby question, but it part of a script I was messing around with.
Basically I'm making a wrapper for mciSendString to invoke Windows audio library using Win32API so that I can make a replacement Audio module for XP/VX that has a lot more functions to it. All went pretty well, and most of the actual functionality is complete, I even made a little wrapper for the default Audio module so that it works with the current functions, but I ran into a bug that I have been trying to figure out for the past few hours to no avail.

What's happening is when a sound effect is played (it likely does it with everything, just stands out the most with SE), it sounds as if the file is being played twice in rapid succession, milliseconds from each other. I have stared at my code and looked at it repeatedly, and cannot see anywhere that that the file is being played twice.

If someone with a fresh set of eyes and a basic understanding of mciSendString could take a look and see what I am doing wrong, I would be most grateful. I have it set so that you can press CTRL to play the cursor SE, or simply open the menu and scroll through the options to hear what I am talking about. The majority of the code is in the Audio::Channel script, and the two method that need picked on are "open" and "play".

Here's a link to the demo.  http://www.mediafire.com/?5499pygnqkbwaaq
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

Without looking at the demo, there are two things that could be causing the problem. One is probably mono/stereo. This is what the actual "channel" attribute is for. A stereo sound effect played as mono may cause exactly that problem that you're having. Another possibility would be sampling rate. An inaccurate sampling rate causes the sound to slow down or speed up. A common problem with sampling rates is that you have to specify the sampling rate on the output and every sound that you send to the output has to use that sampling rate in order to sound properly. This may require you to convert the sampling rate. Now I am not sure anymore if you actually have to do that with mciSendString, but I remember that you did have to do it in SDL (though you didn't with DirectSound and with OpenAL).
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

ForeverZer0

I think I got it figured out, I just had to change the way I do things a bit.

The way I had it implemented, it would not only load files into memory that were different than what was already loaded. If the file was already loaded, i.e. the last file played, it would simply stop and seek to the beginning. I thought this would be a little easier on performance, but I noticed that the first time an SE was played, it sounded fine, but on following playbacks, I had the strange echo. I simply set it to free the previous file from memory no matter and it seemed to do the trick. In all honesty, I don't know what took me so long to think about that... :facepalm:

Thank for the tips, though, Blizz. I was attempting to look into sampling rate, but the only things in mciSendString I could find that dealt with it were for recording purposes. 
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.