- Online Community Forums » Programming Questions » Allegro 4: IT music support

This thread is locked; no one can reply to it. rss feed Print
Allegro 4: IT music support
Member #16,089
September 2015

Hi all. I'm working on an old fashioned DOS game using Allegro 4. (Whenever I've got time...) I've been wondering if anyone who has worked with A4 ever managed to get IT music support working in it.

I've done a little bit of experimentation myself, implementing kode54's dumb library, and I got it working in Allegro on DOS properly, but unfortunately it doesn't seem to be fast enough for my purposes since it needs to run real time on old hardware.

I'm curious if anyone has any pointers in the right direction :)

Chris Katko
Member #1,881
January 2002

I'm positive Allegro 4 with DUMB had all your standard module formats--DOS included.

You're using a fork of the original DOS version. Maybe this original version would be more optimized for older hardware?

- What hardware are you running on? IT formats were "high class" module formats with much more processing / effect support, and TONS of channels (channels = CPU) (32 or 64 channels, IIRC). Try playing a 4 channel mod or s3m and see if it's still a speed problem.

- Run a profiler on a basic app and see where the slowdown is. It might be a simple fix to optimize it.

- Have you considered reducing the sampling rate / quality? Most trackers back-in-the-day NEVER went over 22 KHz. Since DUMB came later, it very likely supports "audiophile" level sampling rates, and interpolation which sounds much better but costs much more CPU (relatively speaking).

Per the git version you're using:


Six resampling quality settings: aliasing, aliasing with bandwidth limiting, linear interpolation, linear interpolation with bandwidth limiting, cubic interpolation, and a compile-time-configurable fast sinc resampler


ALSO, this may be key, per my link docs:


dumb_resampling_quality defaults to DUMB_RQ_CUBIC, which sounds nice but may take too much processor power on slower systems. Try reducing it if
you have an older computer (less than 300 MHz) or if you are trying to mix
an insane number of samples (or both!). See dumb.txt for details on what
the different values actually do.

So my initial hypothesis of "defaults to higher CPU resampling" seems to be correct.

“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Member #16,089
September 2015

Thank you! Yeah, I actually have to admit I probably did not do enough research with my current setup... I didn't try altering the resampling quality. I actually did not know Dumb is a very old project going back to the DOS era...knowing that makes me wonder if changing some of these settings can speed it up significantly.

I'll have another try with the code I have, and have a look at the pre-fork version if necessary.

(I would like it if everything could run full speed on a higher end 486. So far with only Allegro's midi support it does.)

Member #907
January 2001

Impulse Tracker is rather "Pentium" generation.
If you're targetting hardware like Sound Blaster 16, you get only one hardware digital channel, so the mixing is performed entirely by the CPU. Typically, game music modules would be not much more than 4 channels, in order to limit the CPU cost (a standalone MOD player would show < 20% CPU time on a 486 DX2).
Deus Ex title track may be 23 channels, but it was in a game released in 2000.

Member #16,089
September 2015

Hmm, I see. Maybe I should instead be trying for S3M files. Saying that because Jazz Jackrabbit has an S3M soundtrack, and they were able to make it work. I'll have to do a bit more experimenting.

The reason why I initially wanted to go for IT files is because a friend of mine made a lot of tracks back in the day and would be OK with me using them. Or maybe I can use only the ones that have only a few channels.

Bruce Perry
Member #270
April 2000

IT files don't have to use ridiculous numbers of channels.

They are more likely to because it's likely the authors will have used 'new note actions' which allow old notes to continue playing, fading out, while new notes have already started. I think you can control the amount of mixing DUMB does in this case though - there is a variable for the maximum number of channels to include in the mixing loop at any given time. I think it even 'pretends' to mix them so that their positions update and they will come back in correctly if all the other (louder) sounds suddenly go away.

Filters were mentioned, but not all IT files use them.

Good luck :) If you find that the older DUMB is faster, then you may want to raise it with kode54 so he can look into what went wrong. As far as I know, the new DUMB has true volume ramping capability (whereas the one I did used stepped volume changes and a click remover), so that could have affected the inner mixing loops but it shouldn't be too costly in theory.

Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

Go to: