Choco / PrBoom+ and sdl / TiMidity Problem [bleeding ears!]

Hi,

There is a bad screeching sound played during music playback with Chocolate-Doom & PrBoom-Plus while using sdl TiMidity. I am using these EAWPATS GUS patches on an XP and a Vista machine both using Realtek audio drivers.

Here is the ear bleeding Banshee cry on map5 of Doom II at about 1:15 into the song. If I don’t quit the game that horrid sound just keeps playing on top of itself getting louder and louder.

I first noticed it in PrBoom-Plus then in Chocolate-Doom so I naturally tried older sdl_mixers with no change. I’ve checked ZDoom and Eternity and they do not have this problem. I tested all of the PrBoom releases and non of them have this problem either.

I checked the PrBoom-Plus releases until I found it was still working fine in 2.4.8.1 but was broken in 2.4.8.2. Noting the changelog for 2.4.8.2 mentions Chocolate-Doom I then checked Chocolate-Doom’s releases and found it working fine in 0.1.4 but broken in 1.0.0.

I really hope this can be fixed because using TiMidity on my Vista machine is the only way I now know to allow the in game volume adjustments to work independently from the wave volume. There is a TiMidity midi driver dll thing but it is old and I haven’t tried it in a while but I do recall it’s volume had to be set independent of any programs which kinda sucks.

Let me know if you need any more info. Thanks so much!

This has actually been reported at least twice before, but so far the devs have been unable to fix the problem. But if it does indeed work properly with various older port versions as well as Eternity, then maybe there's still hope.

The TiMidity driver was actually last updated as recently as December 2008, so maybe you could try using the latest version as a workaround (get it here). IIRC, it worked out pretty well for me when I last tried it.

Has any Doom port looked into FluidSynth? Apparently ScummVM uses it.

Yeah Janizdreg, I think that is the version I tried (not as old as I thought). The problem is that you have to select it as the midi device in Windows which is easy in XP, difficult in Vista and might be near impossible in 7... I find various reports of registry tweaks and little apps made to do the registry tweaking are available however I have not bothered to get that far as my Vista machine won't even let me save changes to the TiMidity.cfg (saying it might be open elsewhere though I have no difficulty with it on XP) and IIRC that is where I have to adjust the volume and tweak a few settings.

I really hope something can be done since it used to work in Choco and PrBoom+ and still works in the latest PrBoom.

This happens to me too. PrBoom-Plus under Linux with eawpats on Timidity.

I remember reading somewhere (no idea where) that this was caused by a dodgy instrument in the patchset. Maybe if you switch to shompats or something else it will go away.

From the start I had thought it was simply an issue with the eawpats (or a dodgy instrument in the patch) but it works fine in earlier Choco-Doom and PrBoom-Plus releases as well as every PrBoom release and at least the latest Eternity release.

I switched the patches to the goemon and the incomplete freepats to see how they played and, well, it IS broken a little differently with these patches though still only broken in the later releases of Choco-Doom and PrBoom-Plus.

It seems ChocoDoom 0.1.4 was using sld_mixer 1.2.6.0 and PrBoom-Plus 2.4.8.1 was using 1.2.7.0 when they were working. After they both updated themselves and updated the sdl_mixer to 1.2.8.0 they were broken. PrBoom 2.5.0 uses 1.2.8.0 without issue and Eternity seems to use 1.2.11.0? without issue.

As another test I used Eternity’s sdl and sdl_mixer 1.2.11.0 in the latest PrBoom-Plus and there was no change. Then I used the sld and sdl_mixer 1.2.7.0 from PrBoom-Plus 2.4.8.1 in PrBoom-Plus 2.5.0.6 and again there was no change. Still broken.

All I know is that when I listen to the song in PrBoom/Eternity or the older Choco/PrBoom+ it sounds great and I can sometimes hear that ‘sports whistle’ instrument very, very faintly if I really listen for it. Not broken.

Vista’s midi is just too laud most of the time and maps have different midi’s at different volumes so I’m always adjusting the volume to play Doom. I play quake without it’s music or by listening to my music collection so maybe I could get used to Doom the same way or just play in another port till this gets resolved whether it’s the ports or sdl or Vista/7 finally working properly. I love the ports though and all the great work that goes into them and the others.

HackNeyed said:

I checked the PrBoom-Plus releases until I found it was still working fine in 2.4.8.1 but was broken in 2.4.8.2. Noting the changelog for 2.4.8.2 mentions Chocolate-Doom I then checked Chocolate-Doom’s releases and found it working fine in 0.1.4 but broken in 1.0.0.

2.4.8.2 @ 2007-10-16 said:

[+] New mus -> mid conversion code thanks to Ben Ryves benryves at benryves dot com. This removes bugs and plays back a lot of music closer to Vanilla Doom - eg. tnt.wad map02.

I do not use timidity, so ask fraggle, Ben Ryves or SDL guys. New mus to mid converter is better for me. TNT.WAD MAP02 sounds like utter shit (with timidity too) with old converter which is used by vanilla prboom and eternity.

P.S. PrBoom/+, Eternity, Chocolate and other SDL based ports do not have even single line in sources to support timidity. It is fully on SDL_mixer side.

entryway said:

I do not use timidity, so ask fraggle and Ben Ryves. New mus to mid converter is better for me. TNT.WAD MAP02 sounds like utter shit with old (prboom, eternity)

Well, I say timidity as a generic term. Placing the EAWPATS GUS patches in C:\timidity and editing the timidity.cfg that comes with the patches allows them to be used for midi playback through sdl on a fresh Windows install without actually having installed timidity. I'm sure you already know.

Anyway, yes TNT map02 does not sound very good in PrBoom, Eternity, Choco 0.1.4 or PrBoom+ 2.4.8.1 where as PrBoom+ 2.4.8.2 and Choco 1.0.0 sound better and are still identical to each other. I guess the new mus to midi and old GUS patches are just broken for some of us. Like I said I'll work something out and at least my netbook has XP on it since it also needs the wonderfully fast PrBoom-Plus renderer.

So, yeah, thanks anyway for the reply and all the hard work on the speedy engine.

I will contact Ben and politely explain the situation, perhaps he will be able to fix it, perhaps the problem lies elsewhere. I hope it's not in Timidity or SDL.

Super Jamie said:

I hope it's not in Timidity or SDL.

But problem does not exist if you use MIDI, not timidity

Super Jamie said:

I will contact Ben...

Thank you Jamie, you're Super.

I think I have fixed it. At least doom2.wad map05 and tnt.wad map02 sound well.

Try the latest 2.5.0.7 beta:
http://prboom-plus.sourceforge.net/history.html

Many thanks for fixing that; I haven't been able to replicate the issue myself in a more easily controlled environment (e.g. using timw32g.exe with the EAWPATS GUS patches mentioned in the original post) so I'm glad it now works!

I'm not entirely sure how the fix works, though, and why mapping MUS channel numbers directly to MIDI numbers (excluding 9 and 15, which are swapped) causes issues in some environments but not in others... :-\

benryves said:

Many thanks for fixing that; I haven't been able to replicate the issue myself in a more easily controlled environment (e.g. using timw32g.exe with the EAWPATS GUS patches mentioned in the original post) so I'm glad it now works!

I'm not entirely sure how the fix works, though, and why mapping MUS channel numbers directly to MIDI numbers (excluding 9 and 15, which are swapped) causes issues in some environments but not in others... :-\

I came here to post exactly the same thing. I checked out the fix that entryway applied to the PrBoom-plus mus2mid code (which comes from the older Boom mmus2mid code) and found it more than a little confusing, but I think I've figured out how it works.

Previously, MUS channels were mapped to MID channels directly, with 9 and 15 (percussion) swapped. Now the channel numbers get "compacted" down to use the first channel numbers first. eg. if your MUS uses channels 6, 7, and 8, the generated MID will use 0, 1 and 2 instead. FirstChannelAvailable() searches the existing mapping table to find a new MIDI channel that has not been used yet, by finding the maximum existing channel and adding 1 (there is a special case here that it can't allocate channel 9 as it's the percussion channel).

All in all, this shouldn't really make any difference as it's just shuffling the channel numbers around a bit. Perhaps timidity has some bug with higher numbered MIDI channels?

EDIT: Actually, isn't there a bug in this code? As soon as a percussion note is played, channel 9 gets allocated, and all subsequent MIDI channels will be higher than this, so potentially the first 9 channels (0-8) end up unused?

I expect it is a bug in Timidity (or maybe SDL) but I'd like to thank you guys for looking into it and Andrey for applying a fix all the same.

Timidity was last updated in 2004 hence could probably be assumed inactive, such a specific case would probably be lowly prioritised for a project as large as SDL, so it's nice that still-active projects like this can provide a solution.

Especially for those of us on Linux where Timidity is pretty much the only option, your efforts are appreciated.

entryway said:

I think I have fixed it. At least doom2.wad map05 and tnt.wad map02 sound well.

Try the latest 2.5.0.7 beta:
http://prboom-plus.sourceforge.net/history.html

It's fixed for me in the few songs I've listened to here. Thank you very much entryway! Thank you everyone.

Does this behavior occur in Odamex as well? Can somebody please test?

Ralphis said:

Does this behavior occur in Odamex as well? Can somebody please test?

It dose. I just tested.

fraggle said:

EDIT: Actually, isn't there a bug in this code? As soon as a percussion note is played, channel 9 gets allocated, and all subsequent MIDI channels will be higher than this, so potentially the first 9 channels (0-8) end up unused?

You'll be pleased to know that I've added entryway's fix to Chocolate Doom's mus2mid code. Sort of, anyway - it does the same thing but it doesn't have the above bug :-) The banshee whistle is gone now.

Excellent, thanks for the fix! The glitch was actually my main issue with using TiMidity too, so this makes me one happy camper indeed.

HackNeyed said:

I really hope this can be fixed because using TiMidity on my Vista machine is the only way I now know to allow the in game volume adjustments to work independently from the wave volume.

I do not know why it happens for you (do you use Creative or something?). On all machines with Windows7 I tried (all of them have on-board Realtek) - in-game MIDI volume works just awesome. No issues, it works independently from the SFX volume. Yesterday I tried prboom-plus on computer of my friend - no issues, again. Am I so lucky or what? Probably Windows7 != Windows Vista? I thought they are the same.

entryway said:

Am I so lucky or what?

Apparently you are very lucky and should play the lottery! Unlike the rest of us.

@fraggle

That is very good news though I'm keeping an eye on the opl-branch mainly. Because that feels very classic to me and when it matures I hope it spreads like wild fire (at least to PrBoom-Plus and EE)! ZDoom's is very good but with everything else ZDoom does, opl seems out of place for me. I haven't test the opl-branch much but AV map04 is all wrong. Keep up the great work though cause some of us are really gonna love it!

HackNeyed said:

Apparently you are very lucky and should play the lottery! Unlike the rest of us.

Oh, ok :) I have tried it again and have understood issue.

HackNeyed said:

Apparently you are very lucky and should play the lottery! Unlike the rest of us.

I'd still like to know what these morons were smoking when they changed this. Is it really that hard to premultiply the sound data with a volume setting before sending it to the wave output?

HackNeyed said:

@fraggle

That is very good news though I'm keeping an eye on the opl-branch mainly. Because that feels very classic to me and when it matures I hope it spreads like wild fire (at least to PrBoom-Plus and EE)! ZDoom's is very good but with everything else ZDoom does, opl seems out of place for me. I haven't test the opl-branch much but AV map04 is all wrong. Keep up the great work though cause some of us are really gonna love it!

Thanks :-) Like you point out, there are still quite a few MIDIs that don't sound right. A few months back I actually started disassembling the OPL playback code in the Vanilla executable so that I could fix the last few errors. However, I unfortunately lost what progress I'd made on that when the SSD in my laptop died.

Am I right in thinking that the MIDI volume problem isn't that the in-game volume slider doesn't work, but rather that it works by changing the system MIDI volume? It ought to be possible to change the SDL_mixer MIDI code to do its own volume level scaling if necessary (like GZ suggests).

fraggle said:

Am I right in thinking that the MIDI volume problem isn't that the in-game volume slider doesn't work, but rather that it works by changing the system MIDI volume?

In game, lowering the music slider lowers both the music volume and the sfx volume (not the sfx slider) at the same rate. However the reverse is not true, lowering the sfx slider lowers the sfx volume leaving the music volume (and slider) unaffected.

In my case I can hardly hear the sfx over the music when both sliders are maxed and since I can, at that point, only lower the sfx independently it got pretty annoying. However I found that using these TiMidity/GUS patches through sdl_mixer gave me independent volume control on Vista.

Sorry to double post but I was watching Belial's map02 max run of dv.wad and again with EAWPATS the song goes bad at 0:37 AND PrBoom-Plus crashed with a signal 11 around the 0:45 mark when I was fullscreen at 640x480. I can't always reproduce the signal 11 crash as it happened but if I change the ratio to 16:10 and have the screen at 640x480 or 640x400 it always happens sometime between 0:42 and 0:48.

So yeah, entryway, I'll get a crash report and my config to you sometime for the signal 11 crash if you want and I hope every broken song doesn't require some special exception in the code to fix it. :(

As far as I can tell, the fix may as well randomly shuffle channel numbers around, at least then if something does go wrong you could restart and have a chance of it working that time around. I cannot see how the fix helps otherwise, and what causes the problem - is there a bug in Timidity that is triggered by using a particular instrument from a particular patch set on a particular channel? I couldn't replicate the issue on my machine, so am not sure what I can suggest!

HackNeyed said:

Sorry to double post but I was watching Belial's map02 max run of dv.wad and again with EAWPATS the song goes bad at 0:37 AND PrBoom-Plus crashed with a signal 11 around the 0:45 mark when I was fullscreen at 640x480. I can't always reproduce the signal 11 crash as it happened but if I change the ratio to 16:10 and have the screen at 640x480 or 640x400 it always happens sometime between 0:42 and 0:48.

So yeah, entryway, I'll get a crash report and my config to you sometime for the signal 11 crash if you want and I hope every broken song doesn't require some special exception in the code to fix it. :(

Probably EAWPATS are buggy. Timidity MIDI driver from the second post works perfectly, again. This time classic prboom with old mus2midi also goes wrong.

entryway said:
Probably EAWPATS are buggy. Timidity MIDI driver from the second post works perfectly, again.

I tried EAWPATS with a standalone Timidity-based player (timw32g.exe) and the files generated with the old code (mapping MUS channels directly to MIDI channels) sounded fine.