MSU-1 support in Snes9x

Just a little something I've been working on for the last week or so...

https://youtu.be/RhdW-HxwyPg

If anybody would like to test it out:
Windows binaries
Linux source

I could really use feedback on any desync issues. BS-Zelda would be a good one to test for that.

Caveat emptor, I'm not 100% sure what compile-time features are/aren't enabled in the Windows builds, other than the fact that I know I built them *without* FMOD support. Treat them as the test builds they are. Don't bother reporting any non-MSU1 bugs against these binaries.

Files use the SD2SNES naming format, i.e.
gamename\
-gamename.sfc
-gamename.msu
-gamename-#.pcm

no manifest necessary. Just copy the whole game folder into your ROMdir.

What I like most about you is that you're a "get shit done" kind of guy.

Most people look at a tough problem, go "boy it'd be nice if someone worked on that!", and then go and do something fun instead.

Even when you're faced with a tough challenge and no idea how to do it, you go in there, figure it out, and persevere to completion!

My heartfelt thanks and congratulations on pulling this off! :D

No problem, it was a lot of fun (except for the whole two days I should have just stayed in bed and off the internet thing ), and it's always really neat to make something that actually *works*. I don't code nearly enough, and part of the problem is not being any good at coming up with ideas, so having one just sitting in front of me like that was nice for a change. Glad we could get everything worked out before I had things ready to go public (at least moreso than the already public GitHub tracker).

im getting alot of crackling in games like mega man x and super mario world here's an example
http://puu.sh/se3In/d48b47012f.mp4

Can you provide a screenshot of your audio settings?

they were at default. ive messed with them quite a bit trying to fix it. not able too. doubt its the settings themselves

Change from XAudio2 to Snes9x DirectSound.

"Crackling" is usually caused by either audio buffers being underrun/overrun, A/V sync problems, (in many emulators) "complications stemming from use of Vsync", or sometimes time-sharing issues relating to multi-core systems. Audio crackling when the emulator loses focus or regains focus is also a common problem in some emulators. The OS you're using (WinXP vs. 7 vs. 8 vs. 10) matters too, oh and video drivers to boot. Fullscreen vs. windowed also matters. It's all complicated, in other words.

As such, sometimes fooling with video settings can help too. For example, in SNES9x, I use a video output method of Direct3D, and I do have Vsync on. But I run the emulator purely in windowed mode.

ive done all that ive messed with video settings, audio settings, everything audio crackling still occurs on some games

I tested both unofficial SNES9x 64-bit builds, as well as qwertymodo's SNES9x binary here. I used both Super Mario World and Megaman X as test subjects; I could not reproduce the problem demonstrated. I *was* able to get some occasional "crackle" in SMW during the intro sequence, but it was caused by what I described in my previous post. Simply toggling "Sync Sound" off, then back on, rectified the issue. I can also get "crackling" to happen if I set the buffer size (on my setup -- it varies per card/setup) to anything below 48ms -- but the way the crackling sounds differs from yours (again: it's related to what I described in my previous post). If you want video/audio recordings that prove what I'm saying, I'm happy to provide them.

I then checked out the MP4 you linked -- that sounds like a gain-related problem. The "crackling" sounds more like clipping, and happens at consistent intervals that match up with specifics kinds of volume levels (possibly caused by certain samples).

That said: I have a sound card -- Asus Xonar DG -- that exhibits this problem when the "internal" volume control ("Mixer") within Asus' control panel applet is set to anything above about 75%. (This is 100% independent of the Windows volume control per-app, as well as the volume for overall system)

Does the problem happen for you on non-qwertymodo SNES9x builds? In other words, is it specific to his builds for you? What exact Windows version are you using? Are you sure your Windows output device has "full-range speakers" enabled?

I would check the volume levels of literally everything in Windows. Since Windows 7 (maybe Vista?), there are a gajillion places to examine, ranging from the overall system volume to per-app to internal volume levels within the properties of the output device to things even deeper (often controlled/managed via chipset driver control applets, ex. Realtek, Asus, Creative, etc.).

P.S. -- One-line responses when discussing such an issue are generally considered rude. Technical problems involve clear/concise details, albeit often verbose. Take the time to write down all the stuff you've tried so that we know, and not just "I've tried everything". :P

I'm hearing from other people that the .pcm files for MMX are way too loud, which is probably a holdover from the SD2SNES volume issues on older firmwares, which would be right in line with koitsu's diagnosis of clipping. Try my aLttP DX patch with the audio pack from the README and see if you still have the same issues: http://www.romhacking.net/hacks/2234/

lol i do play link to the past dx. i only get the problem with super mario world and megaman x so far

Well, then there's your answer. Sorry, there are a handful of poorly encoded .pcm sets out there due to the aforementioned SD2SNES volume issue, and there's nothing I can do about that. Unfortunately, now that the issue is resolved, a lot of the packs still haven't been updated to reflect that. You'll have to bug the authors to fix their audio packs.

What format is the PCM? 16 bit I guess, but big or little endian? And how many decibels too loud are these rips? With this info, I can make a correction tool.

16-bit signed stereo little endian @ 44100hz, so in byte form:

<'M', 'S', 'U', '1'>
<4-byte loop offset in samples: value is 8+vaue*4>
<low left channel, high left channel; low right channel, high right channel>

The sd2snes volume ran at 3.3V of the 5V range, so it was ~66.7% of the volume it should have been. The presuming wisdom is that the volume was scaled by sample*1.5. So to reverse that, you would use sample*0.667.

However, if the audio ended up clamped as a result of the initial scaling, obviously you won't be able to fix that. As such, it would be be better to resource the original material. Or at the very least, alert the user if any samples are >=98% of the max volume range.

Actually, that wasn't the issue after all. He tried running the DAC at 5V and it didn't go well. The real issue was an impedance mismatch between the DAC output and the mixer input, which was fixed by adding a unity buffer between the DAC and the SNES. However, the end result is still essentially the same.

Also, I mentioned this over at RHDN, but it is possible to open the files in Audacity if you want to fix the gain yourself, it's just a tedious process.

Import>Raw Data>Signed 16-bit PCM/Little-endian/2 Channels (Stereo)/8 bytes/100%/44100Hz

Effect>Normalize

A good starting point is -12dB, but it will vary from track to track since it uses peak levels instead of RMS. You'll have to play around with it.

Export>WAV (Microsoft) 16-bit PCM

Run the .wav through WAV2PCM

Copy the first 8 bytes (well, really only the loop point which is bytes 4-7, but it's just easier to copy 0-7) from the original .pcm to the new one in a hex editor.

Or, if you're writing a tool, like byuu said, just skip (and copy) the first 8 bytes, then the rest of the file is just 16-bit LE PCM samples, which should be scaled by 66%, or if you want to get fancy, take the RMS level and normalize the entire pack to ~-12dB that way.

Now I'm wondering if my Hong Kong 97 MSU1 hack was too loud. The single audio track has very little headroom since I basically just used it as-is after ripping a YouTube video.

(note: I am not going to release a second revision of this hack)

higan is the easiest way to tell, just run the game where the bgm is playing at the same time as some SPC SFX and listen for if it sounds balanced or if the SFX seem too quiet/too loud.

Unfortunately, the game in question does not contain sound effects.

I'm making a plan to test an msu1amplify tool that I'm developing that'll apply the needed -3.5 dB correction. To do so I'd need MSU1 PCM files and a means to play them correctly. Which such files exist and are clearly distributable (for instance, not ROM hacks or ports of LaserDisc or similar games)? And which way to play them doesn't need either an SD2SNES (I have the SNES PowerPak instead) or a PC that runs higan at full speed? Can this preview build of Snes9x be relied on for testing?

You can play them in Audacity as previously mentioned, or else yes, the Snes9x build should be usable for testing.