de_doomy

My first attempt at video-making, taking a look back at Doom the Way id Did. Inspired by the likes of MtPain/Civvie/GamingGargoyle, so hope it isn't too shameless. I'm pretty slow so can't promise consistency, but hopefully someone enjoys it!

Happy to report that this issue has now been fixed (credits to ceski) in some source ports as noted on the GitHub issue page. I've only tested so far in the GitHub builds of Chocolate Doom and Woof, but with my delay value set to 100 in the config I'm not hearing any noticeable stutter and music changes are near seamless too!

Funnily enough, there were some early 2000s modules in the Sound Canvas family with SC-55 mapping that had USB outs, but I've never looked into whether or not people have managed to use them on modern Windows, and I also don't know how well their mapping is compared to actual SC-55 units. I've also now posted the issue on the Chocolate Doom GitHub just to document it within the more appropriate channels. In the meantime the older versions of my ports will suffice!

I've done even further investigation and have tested most of the ports I still have installed and have made some interesting discoveries... I've found that some of the older versions of Crispy, Chocolate, Retro etc. can in fact playback the MIDIs without stuttering. My results below: I don't think it has anything to do with my configs (though I'm not 100% sure on that), but I did run Crispy 5.11.1 with a clean default config and still sounded fine. I'm also unsure with that version of DSDA because it sounds like it stutters, but to a lesser extent than the others I tested. It seems like something has changed in the audio playback department between these versions to start causing these issues but I'd have no idea otherwise.

As far as I can tell it doesn't seem to occur in EDuke, though music in that game seems to start after a bit of silence after the level loads so not sure if that's what causes it to be fine, as opposed to Doom's immediate MIDI playing. Seems to work fine as well in System Shock Enhanced. I did some more digging and ran it through an XP virtual machine (with drivers for the UM-ONE) using ZDoom and sure enough, it still stutters.

Hey there, long time lurker, first time poster... I've recently acquired an SC-88VL (which has been sounding phenomenal for the record), but I've noticed a timing issue where at the start of tracks, there will be a slight stutter/hiccup that leads to the first notes rushing before the rest of the track plays normally. I've recorded a sample below, where it is noticeable more on both E2M1 and E3M1. It will also continue to occur again once the track loops back to the beginning. I've tried in both source ports that allow you to select the MIDI device directly (GZDoom) as well as other ports (Cripsy, Woof) where you'd need to use Coolsoft MIDI Mapper/VirtualMIDISynth to override the default Windows GM synth. https://whyp.it/tracks/44962/doom-midi-stutter?token=6eg3Y I've tested it on both a Komplete Audio 6 interface as well as a Roland UM-ONE mk2, and I've only noticed this mostly in Doom, as well as Sekaiju (only once looping from the end, beginning of the tracks sound fine the first playthrough) I know this isn't a support forum and might be stretching how related to Doom this is, but I can't find much discussion if any about this issue and I was just wondering if any of the other folks here who use hardware sound modules on modern systems (in my case, Windows 10), have noticed the same issue occur to them. It's the only thing that's preventing me from completely enjoying the hardware!