de_doomy Posted September 28, 2022 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! 1 Quote Share this post Link to post
Sonikkumania Posted September 28, 2022 Does it occur in other games with midi OST, like Duke Nukem 3D or ROTT? Have you tried all the IWADS? What about sourceports like ZDoom or Zandronum or Skulltag? I really can't help with anything else, sorry, but these just came to mind. 0 Quote Share this post Link to post
de_doomy Posted September 28, 2022 (edited) 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. Edited September 28, 2022 by de_doomy word 1 Quote Share this post Link to post
Lippeth Posted September 28, 2022 I don't have an answer or solution, but all my Roland hardware does the same thing to varying degrees and I always chalked it up to the speed that the hardware receives MIDI data. MIDI files usually have all the non-note data at the beginning of a file, all being read at the same time, and to me it seems like the hardware is just trying to read it all before moving on. I wouldn't say it never bothers me, especially when recording playback for other people, but usually I can get lucky with it looping or sometimes just record multiple takes and splice the good one into the full song. And when playing games, that hiccup at the beginning of songs has never bothered me, though I do notice it. I want to say that's just how Roland hardware behaves, but hopefully someone has a better explanation, or even a solution. 1 Quote Share this post Link to post
de_doomy Posted September 28, 2022 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. 0 Quote Share this post Link to post
mikeday Posted September 28, 2022 For Crispy I am guessing this might be caused by the changes in this commit. Tagging @ceski for comment. 0 Quote Share this post Link to post
yakfak Posted September 28, 2022 some midis are just a mess :)) it's kind of a good idea not to have a note command on the very first tick, get all the channels initialized and panned first. and i bet some soundfonts initialize slowly during this time an individual fix is really no help if yr enduring a systemic error but you can open a midi file up in whichever sequencer you like and draw a blank pattern at the start of each channel which often fixes these things 1 Quote Share this post Link to post
ceski Posted September 29, 2022 (edited) On 9/28/2022 at 5:47 AM, mikeday said: For Crispy I am guessing this might be caused by the changes in this commit. Tagging @ceski for comment. Thanks for the heads up, I was able to reproduce this with real hardware. I have a solution but it'll take a while. Edit: There's more work to be done with this. Edited September 30, 2022 by ceski 4 Quote Share this post Link to post
FozzeY Posted November 6, 2022 I noticed the same issue on Windows 10 -> CoolSoft MIDIMapper -> UM-ONE mk2 -> SC-55 mk2 in latest versions of Chocolate and Crispy when a new track starts, looping seems to be fine. PrBoom+ with SDL set as the MIDI player has next to no stuttering, but the music sounds muffled, which is why I suppose PortMidi is recommended for hardware - that has stuttering on track start as well. 1 Quote Share this post Link to post
Doomkid Posted November 6, 2022 I got an SC-55 + UM-ONE a bit ago and can confirm the stutter is there. It's so brief that I don't mind it much, but were I to record from the SC-55, I'd go with what yakfak suggested and simply add some blank space at the start of the MIDI to let everything get ready before playback starts. I know this is only topic-adjacent, but if Roland sold a new version of the SC-55 with native USB out, it would definitely sell. These days there'd be no excuse not to load a few different banks/soundfonts in there too. 3 Quote Share this post Link to post
de_doomy Posted November 10, 2022 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! 1 Quote Share this post Link to post
FozzeY Posted November 20, 2022 PrBoom+ has a "mus_portmidi_reset_delay" config option just for this sort of thing, it turns out. 1 Quote Share this post Link to post
de_doomy Posted December 16, 2022 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! 0 Quote Share this post Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.