I maintain a legacy system built up from old hardware, mainly for playing old DOS games (easier and more headache-free than trying to use DosBox):
----- -----
Pentium 166

192Mb RAM (the max that the old motherboard will support). Note that due to 'MicroChannel Architecture' bugs, DOS XMS/EMS drivers only recognize 64Mb of this ram. Does not cause problems. Occasionally, I've used this old computer as a 'backup" and installed Win98SE on it, and the full 192Mb RAM is available; and used an external (serial port) dialup modem to get onto the internet.

NO modem is installed internally.

2Gb Hard Drive

SVGA chip S3 Trio 64V, 2Mb VRAM

Old Creative Labs SoundBlaster Pro (CT-1600).

DOS 6.22
----- -----
I Installed the most recent DJGPP suite under DOS 6.22, and Allegro 4.2.2. Allegro builds just fine. The example programs run, and I have no problems compiling and running the 'Vivace' tutorials, and a couple of other Allegro/DJGPP sources that I have found on the internet.

The problem is that playing .WAV files (or sound samples in packed files) sounds terrible. In the Allegro DEMO program ('asteroids'), the Allegro example program (EX_SAMPLE), and others, .WAVS sound very distorted.

It sounds like the samples are... 'boosted' (volume artificially boosted) and badly clipped. Imagine overdriving a set of speakers far past specs.

I am hoping that this is a KNOWN problem with a KNOWN solution, otherwise I am just going to have to forget about using Allegro (in this environment) or try to find the cause myself, and re-build it.

Someone of the SourceForge mailing list suggested that I try an earlier version of Allegro, but it wouldn't build under DJGPP; the build kept failing early in the process (Allegro 4.0.3; he suggested it MIGHT work better under DOS).
----- -----
- Thanks, Jeff

Have you tried changing the sound settings in allegro.cfg?

(gnolam);

Yes - I should be more specific about what I have tried so far.

I've used the Allego 'SETUP' program, and I've tried every thing I can think of;

volume

number of channels for both digital sound and midi (I can't remember what this is specifically called - either '# channels' or '#voices') (Allegro docs indicate that this can go up to 64 - I've tried various values ranging from 1 to 64)

Other settings dealing with sound (BTW the 'Pan' setting works correctly - changes the L/R balance)

I've tried modifying the Allegro.cfg file manually.

I've tried various combinations.

I got a hold of the old legacy Creative Labs software package - DOS and Win31 - and tried modifying the SBPro mixer settings BEFORE invoking allegro applications.

The symptoms seem to indicate that in Allegro 4.22, for DOS/ SoundBlaster Pro (Creative Labs CT-1600 card); that the Allegro library (for some reason) ends up processing all sound files - boosting the volumes WAY UP, and then clipping them. For example in the Allegro Demo ('asteroids'), the voice that says "Welcome to Allegro!' and screams whenever the ship is blown up, is BADLY distorted. Imagine feeding a sound source to an amplifier, out thro a small 8 ohm speaker, turn the volume up enough to damage / blow the speaker. But the speaker still works (sort of), but the paper cone is ripped to shreads. OR - playing a voice through a speaker, turning the volume WAY up, but the speaker is enclosed in a metal coffee can.

I should say that the SBPro works FINE with other apps / games. ONLY apps compiled with DJGPP / Allegro 4.22 are distorted. I tried resampling some WAVS to different freqs (on my windows computer) - that didn't help. I have NOT tried yet to depress the volume stored in WAVS yet - (I'll get around to this tomorrow) - example re-working some waves to 0.50 and 0.25 volume. But from the symptoms, I don't think it will work - I've tried some 'quieter' wavs already.

One old game I have - JJFFE 2.8b for DOS (a re-work of Elite III : First Encounters, rebuilt by John Jordan) used an older DJGPP / Allegro (version 3. something I think) sounds just fine. But I can't get older versions of Allegro to compile under the recent DJGPP.

I would rather get 4.22 to work correctly - I am hoping someone has been through this before and knows what do to. If necessary, maybe I could 'fix' the applicable Allegro 4.22 source and rebuild it.

In the little I've used Allegro 4.2 with DOS, I've had no luck with SoundBlaster cards. It would actually crash and burn. I don't ever recall having the problem with Allegro 3 or Allegro 4.0.

So in short, it wouldn't surprise me if something is broken. It would probably be easier to try to get Allegro 4.0 up and running. Any compile error you have is probably easily remedied.

Matthew:

Thanks, thats actually a very valuable clue. It indicates that the problem occured somewhere in Allegro development; that something got broken along the way.

Trying to get earlier versions of Allegro to build under recent DJGPP: its complicated. The build for 4.03 halted at 'fli.c', I think. At present, this seems like the most complex of the options available (at least right now...). I'm just not sure - seems like it would take a long time to figure out why it can't build under recent DJGPP.

I think what I will do, based on what you've told me, is to download Allegro 4.0 and maybe some 3.xx versions. Study the code. Compare it to 4.22. Try to spot what was 'broken'. IF I can determine anything (definite), I can try 'fixing' the Allegro 4.22 code myself, and build a special version for my machine.

- Thanks, Jeff

It's actually not that easy to get Allegro 4.0 compiled with recent versions of GCC (don't ask me for the details, they changed something in how the compiler treats some constructs that used to be considered legal but aren't anymore).
Instead of randomly looking at the code, have a look at the changelogs that come with each release and try to pinpoint the problem there. Have you tried earlier 4.2 releases?

I should warn to take my recollections with a grain of salt. I know that sound code crashed the demo on pure DOS when I last tried, and I'm assuming it was the Allegro 4.2 branch since that has been out for a while.

It's possible it never worked on 4.0, but I think that would have been spotted back then since DJGPP was still widely being used, especially under Windows 98. But I know for sure I never had that problem with Allegro 3 under DOS.

Allegro's mixer has plenty of clipping protection, unless something is multiplying the samples way way above the intended target. Something that could cause this, though, is if Allegro is giving the wrong information on the expected signedness of the samples. Also, I think the SBPro can only do 8-bit sound? I'm not sure how well that's tested, there could be some improper scaling for that..

Thanks all for more answers and further information....

In short, it sounds like I have some hacking to do.

For that matter, in the long run all I need for DOS / DJGPP is some videocard code, soundcard code, joystick and input code, and game timing functions. SVGA code would be nice. By the time I get done studying various versions of Allegro, I could probably just create my own mini-library; sort of an 'Allegro Lite'. OR look for another game library (DJGPP compatible... or Open Watcom, I downloaded ALL of the Open Watcom for DOS files, but haven't gotten around to studying them yet).

Kitty Kat:

Yes; I tried various WAVs; 8 and 16 bit, and also the same WAV that had been resampled to different frequencies (originally it was 8 bit unsigned, 8Khz). Allegro 4.22 does this to ALL WAVs, at least for the SoundBlaster Pro under DOS.

Yes, because the mixer works in signed 24-bit integers internally (regardless of the source sound), and scales down to the appropriate bit depth and toggles the sign bit as needed afterward. If the mixer is toggling the sign incorrectly, scaling down incorrectly, or getting the info incorrectly from the card, it doesn't matter what the wave file is.

You could, but you'd be reinventing the wheel.

Good luck with that, but don't waste too much time on it.

I'll repeat what I said before, try to find the exact version number where things stopped working. Browse the changelogs, check 4.2.0 and/or the 4.1 WIP series (negelcted to mention those). That will be far more useful than looking through 4.0 or 3.x code to try and find the problem.

I can confirm, I experienced that early Allegro 4.0x, or one of the last 3.93x betas, made sound shriek in DOS.

You can try this link for a set of DJGPP/Allegro versions that can (for example) compile Dosdoom.
http://www.resurrected-entertainment.com/2007/07/15/getting-dirty-with-dos-doom/
The Allegro archive contains the compilable examples, so you can check that sound is ok on your machine.

At home I have some CDs with programming stuff from this time. I'll see if I can find more precisely what was the last version of Allegro I used in pure DOS.

In any case, I recommend the Allegro 3 series as it's really tailored for DOS programming, focused on VGA / VESA etc.

Audric:

THANKS for that link! It's probably exactly what I needed. I archived everything from that link and burned it to a CD; the Doom Source, pre-compiled Doom, AND those specific DJGPP packages / versions.

There is a good chance that it will work for me.

I've been up all night, so this evening (I need sleep!) I will install that version of DJGPP / Allegro on the hard drive. Hopefully the Allegro (3.11) examples will sound OK. Than I will make a pass at compiling that Doom source.

... MUCH appreciated.

UPDATE:

Okay... I've done several clean installs of DJGPP with fresh, clean builds of a few Allegro versions.

With Allegro 3.1, 3.11, 3.12, 4.00, and 4.03, the SoundBlaster Pro is working just fine in the Allegro Setup program, and the Play Samples example program.

NOTE: For some reason, in the 4.22 CHANGES log (and in some other later versions) 4.03 is left out for some reason? The CHANGES logs progress from 4.0.2 directly to 4.1.0

Allegro 4.1.0 is working okay.

Working backwards : The SBPro presents badly distorted sound in Allegro 4.22 and 4.20.

Allegro 4.1.18 : the SBPro does NOT work okay.

Therefore : the bug occurs somewhere between 4.1.0 and 4.1.18 (4.1.1 to 4.1.17)

Evert: I took your suggestion, and exhaustively searched the CHANGES log (from 4.2.2), between 4.1.0 and 4.1.18. There is NOTHING definitive, nothing that leaps out as to a possible culprit.

Between 4.1.0 and 4.1.18 there are 17 versions to check. That hard drive is really getting thrashed; between doing fresh installs of DJGPP and fresh builds of Allegro - and the CHANGES log presents no definitive clue.

I'm going to sent another message to the SourceForge mailing list - the first message I left (in alleg-main) didn't really result in useful responses (just 'did you try 4.03?'). I think I will send one today to alleg-developers. Hopefully they won't get too mad - I'll try to be polite. I think its justifiable in that the CHANGES log isn't helping to steer me in the right direction.

The only other alternative is to 'divide and conquer'; pick a revision close to the middle between 4.1.1 and 4.1.17 (inclusive), and if that one works, then move upwards (by 'half') and if it doesn't work move downwards. Too tired to do this today - I'll check later to see if anyone has input, and then proceed this afternoon or this evening. Maybe the developers have something.

Perhaps someone could tell you which source files are likely to be at fault. You could look at the differences between them, perhaps via the online SVN repository if it goes back that far.

Are you sure? My guess is you're looking for something that affected the clipping or arithmatic for Allegro's mixer, not something that is SBPro specific. Anything that is related to the sound code is suspect.

You can delete versions as you've cheked them, but I understand it's a chore.

Most (all?) of us read the Development forum here as well (actually, I get them as e-mail as well); do as you prefer, but I for one won't say anything else on the mailinglist than I do here.
The good thing about asking for support on the forums is that you can get response from people not directly involved with Allegro's development.

This is what I would suggest you do, actually.

I suspect something related to the mixer, which might be called mixer.c (can't check at the moment). Anything in allegro/src/dos/ relating to soundblaster code is also suspect, but less likely to have been recently modified.

4.1.18 is around the time I redid the mixer, IIRC.

Kitty Cat:
I'll take a look at the CHANGES log, and I might check 4.1.17 next then.

Evert:
I took steps to make it easier when I first started experimenting. On the C:\ drive of that 'DOS computer' I have a directory 'F_DJ'. Since GCC423 can't properly build all versions of Allegro (just Alleg 422, apparantly, I had to step back to GCC 2953 even for Alleg 420), I have a three or four GCC.x.ZIPs there, as well as the rest of the DJGPP package. Then I had F_3, F_41 and F_42; every Allegro .ZIP from 3.1 through 4.22. I've since deleted F_3 and F_42.

I might very well test 4.1.17 next, but otherwise if I use the approach I mentioned I COULD have it narrowed down in about the next four builds... just getting tired of it.

To be honest, when I read the changes log, I just 'scanned' through it visually. Then I did a search for 'sbpro' and 'soundblaster' (in the text editor). I also searched for 'sound' thinking that should catch anything. There were some items, but they weren't mixer related, they had to do with a couple of other drivers and also windows issues. After the coffee kicks in, I'll serach the changes log for 'mixer'.

Oh well, in any case, almost done. When I narrow it down to the exact point the problem starts, I'll compare code sections between two adjacent versions. Hopefully it's something that I can fix myself. I also want to add another joystick type (I haven't even looked at the joystick / setup sources yet), and hopefully correct Alleg 422. The 'latest stable release' produced noticably higher framerates in soem of the examples, and I also want to use the latest GCC / GPP.

- Thanks all

MAJOR UPDATE:

EVERT and KITTY CAT-

Thanks for your input; MUCH appreciated.

I searched the changelog (between 4.1.1 and 4.1.17) for 'mixer'.

Kitty Cat: If you are 'C.R.', then you made changes to the mixer code in 4.1.15, according to the changelog.

I built Allegro 4.1.14, the SoundBlaster Pro sounded good.
I built Allegro 4.1.15, the SoundBlaster Pro sounded like an angry banshee that was out to destroy the world. Problem located.

Now to compare the mixer code in 4.1.14 and 4.1.15. Hopefully(?) I can apply a 'correction' to 4.22.

And also add a new joystick type - 'Standard' 2 button joystick with throttle. Allegro setup offers 'CH Flightstick Pro' (which includes a hat, among other things) - I am using an old basic CH Flightstick (just 2 buttons and a throttle) for my DOS computer. If I select Flightstick Pro, Allegro DOES read the throttle OK though.

Kitty Cat: Just in case I run into problems - if it is convenient, and you can remember for back then (Alleg 4.1.15 / mixer), if you have any advice / input, it would be appreciated. I'm going to take a break now... I imagine I can correct the code for the mixer / DOS / SoundBlaster Pro myself, but you never know.

-----

Somewhat related : If I can modify 4.22 and get it running the way I want, then I imagine I will be satisfied with 4.22 as long as I am only programming in DOS / DJGPP (I also program in Borland C++ 3.0 and TASM on that DOS computer - but those don't offer protected mode features, which is why I got interested in DJGPP recently).

I used to do Windows programming (in the Win98 / Win98SE / WinME days) ; MSVC6 and the DirectX SDKs. But I've been away from it for awhile. I'm a little hesitant to try programming tools on my state-of-the-art Vista machine. I DON'T want to do experiments that might mean having to reinstall Vista!

So... while I am only interested in DOS programming (for now) is there any real reason to progress past Allegro 4.22 (major post-422 releases only), and the current DJGPP, anyone? Probably not, but I would appreciate relevant input.

THANKS, all.
- Jeff

From my own experience with allegro... it might be in the driver code... I'm not sure though... It's been a while since I compiled with DJGPP... I've been using MinGW since 4.1.18 because I was having the same trouble... Something I noticed though when using DJGPP is that when running in a DOS box the sound was usually fine, but under pure DOS there was trouble... It could just be me mistaking the different versions I compiled, but thought it might be worth mentioning...

If you find the bug then let us know

I'm pretty sure I tested mono, stereo, 8-bit, 16-bit, and the various quality output settings when I changed the mixer. Some quick looks through the code and I don't see anything out of place.

Do you know what output mode the card is outputting (8/16 bit, mono/stereo, quality 0/1/2, etc)?

You know what... Know that I think about it I think it was a problem with the wave files I was using... An old version of Cool Edit saved some files with an invalid header... Not sure if that helps though...

Ron Novy;
I don't think that the individual WAV files are the problem.

In Allegro 4.1.14 and previous, the Allegro SETUP.EXE sounds just fine, IE when you invoke SETUP -> TEST -> TEST DIGITAL, you hear what you are supposed to hear, a 'bell or gong sound' (I presume from setup's own data file).

For my own test, I invoked the example programs 'Play Sample", and used a WAV from an old DOS game Daggerfall - it is a spoken voice, and it says "Rest well this night, for tomorrow you sail for the kingdom of Daggerfall!". That WAV is 8 bit, I think 11025 Hz, stereo (and pans slightly from one side to the other).

In Allegro 4.1.15 and later, even the Allegro SETUP.EXE is distorted. Instead of a 'gong', it sounds almost like a 'screech' or "shriek". All waves, regardless of resolution, frequency, or ... 'stereoige" (heheh - made up a new word) sound equally distorted. Almost as if you used a sound editor on a WAV (I use GoldWave, thats what I've used for years), and increased the amplitude (volume) in the wav by 500 percent or something, so much so that the waveforms themselves are distorted and the envelope is destroyed (ie there is no envelope - its all maxxed out).

Kitty Cat;
The SoundBlaster Pro is 8 bit, stereo, supports up to ~ 44 Khz (I have the specs). I don't think it has an inherant 'quality' setting (through hardware).

I have it set up (via jumpers, and my BLASTER variable) for address 220, interrupt 5, DMA 1 (some people say that the standard for Soundblaster 1's are INT 5 while SBPro should be INT 7; thats not QUITE true... just a 'tendancy'). DMA sharing is DISABLED.

I've double checked ALL the boards jumpers over the past few days, and double checked the BLASTER= environment variable in all of my AUTOEXEC.xxx's (I'll explain that shortly).

I've used a variety of WAVs in testing post-4115 Allegro, and regardless of the WAVs characteristics, they all sound distorted. In Allegro Setup, I tried all kinds of settings and combinations of settings - different volume, frequency, and I forget what its called, I thought it was # voices (number of channels?). I processed some WAVS, resampled them to different frequencies and so forth, nothing helped. I stuck with 8 bit WAVs though.

I just got up, and so far only 1 cup of coffee. After at least a second cup, I will start with examination of the mixer code for Alleg 4.1.14, 4.1.15, and 4.22. I'll do experiments. If I get 4.22 running for DOS/SBPro, I'll post the solution here (also the added joystick type). It may be a day or two before I post again...

Okay - exlanation about AUTOEXEC.XXX
I have a neat little program in my DOS directory - REBOOT.COM. As I recall, its only about 7 bytes long. It simply jumps through the computer's cold start vector, rebooting the machine. Its handy because it can be called through batch (.BAT) files. I got it from an OLD book; "DOS 5 Techniques and Utilities". To make the program, you invoke the DOS memory editor ('DEBUG'), load about 7 specific hex bytes into memory, and save memory as 'REBOOT.COM'.

In my DOS directory, I have 5 batch files (one of them very recent); XMS.BAT, EMS.BAT, BOR.BAT, RAW.BAT, and now I have DJG.BAT (for DJGPP).

I have fives sets of AUTOEXEC and CONFIG files... AUTOEXEC.XMS and CONFIG.XMS, through AUTOEXEC.DJG / CONFIG.DJG.

Entering the name of the batch file (since they are in C:\DOS, they are always in the path); XMS, EMS, RAW, BOR or DJG, runs the appropriate batch file.

The batch files simply copy 'thier' AUTOEXEC / CONFIG onto the hard drive's root AUTOEXEC.BAT and CONFIG.SYS, and then it invokes REBOOT.COM.

So, if I want to play a game that needs EMS memory (such as Elite II:Frontier or Wing Commander Privater) I just enter 'EMS' from any directory. The computer reboots, and I have 16Mb of EMS allocated, with no CDRom driver loaded (I have a 'NO CD hack' for Privateer). This lets me have as much conventional memory as possible. The path only points to DOS and a directory that contains a hex editor ('HIEW').

'XMS' invokes a more general configuration; no EMS, CDRom driver is loaded, FILES=64, etc. Its good for protected mode programs (Such as DJGPP/Allegro AFTER they have been built and tested). Its good for my DOS version of the RayTracer (POVRay 3.1g, though I rarely use that anymore). The path contains DOS, HIEW, and PICT (a very good DOS image viewer PictView).

'RAW' is just raw. Only DOS is in the path. NO xms or ems driver. I need that to run verious versions of DTA (basically a .FLI/.FLC file maker and image manipulator).

'BOR' is optimized for Borland Turbo C++ 3.0 and TASM.

And finally 'DJG" is optimized for DJGPP, with the DJGPP environment variable and the required SET command, and a couple of specific things in the CONFIG.SYS

This makes rebooting to different configurations very easy.

Sorry for the confusion, I meant Allegro's output mode. Is it outputting stereo/mono, 8/16 bit, and what's the quality setting (should all be found in Allegro's setup.exe). IIRC, the SBPro is limitted to 22khz with stereo output, while you can get 44khz with mono.. or was that the SB2? I forget..

Either way, the only thing I can potentially see as a problem is using mono output with a a non-0 quality setting. Apparently _mixer_init fails to force the mixer quality to 0 for mono output (which it must), even though set_mixer_quality properly forces it. The default quality level is 2..

Kitty Cat;

I haven't had the time to check things just yet - I got sidetracked on a couple of other sub-forums here. When I log off, I will UnZIP Allegro 4.1.14, 4.1.15, and 4.22 in a good place (renaming "\Allegro" to 4114, 4115, and 422 between unzippings) so that I can compare the code - for me, that would be the first step, to see what was specifically changed. Later, apply 'correction' to 4.22 if necessary.

Your second paragraph... argh, I don't remember if I specifically tinkered with a 'Quality' setting. I know that I tinkered both with SETUP and allegro.cfg (and modified autoexec.bat accordingly to point to it), and also modified allegro.cfg in SETUP's directory. I tinkered with everything else, volume, freq, stereo/mono etc. I'll write down what you said (more or less) and look again - if something leaps out at me, I might even rebuild Alleg 4.22 (unaltered) and try again.

Your first para; oops yes I seem to remember something like that. I'll look at the SBPro spec sheet again - I got all of this old hardware second hand, no manuals, and I had to download things from the web. One good thing, is that I actually found the ancient SBPro user software suite on the net, which includes SB-SET.EXE, and a mixer reset / programer thingy; can be invoked from AUTOEXEC.BAT. I have it set to clear / reset the mixer, and set the master / digital / midi volumes to 12 (out of I believe 15 or 16), and CD, mic, aux/line volumes to 0 (since I am not presently using them).

UPDATE:
Kitty Cat:
Based on your last post, I decided to try one more time with Allegro 4.22 (unaltered), and this time to be very thorough on experimenting with ALLEGRO.CFG. It didn't work, I got nowhere. Thats okay, its just being thorough. First, I ran SETUP, did an autodetect, and saved an ALLEGRO.CFG, and backed it up as A.BAK. Then I started changing things in the .CFG. I tried every possible combination for the Stereo setting, number of bits, quality, volume, number of voices, even the Pan setting, etc... no luck. When I do the digital test the SBPro just screeches. So I think it is safe to say that between 4.1.14 and 4.1.15 something was introduced that broke SBpro playback in DOS / DJGPP.

I created three directories now, \4114, \4115, and \422; just the unzipped allegro versions so I can compare sources. I just now looked at \4114 .. \SRC and SRC\DOS, came up with a list of files to examine and their files sizes (to help determine what was changed between versions). I haven't looked at file sizes for \4115 yet (or \422).

The files from SRC\DOS are ADLIB.C, DMA.C, DSNDDRV.C, SB.C
From \SRC are DIGMID.C, MIDI.C, MIXER.C, READSMP.C, SOUND.C, STREAM.C

The reason that I want to look at the MIDI code is that while digital sound is clearly messed up (post-4.1.14), MIDI is also "too quiet". I can't get much volume out of it (though it sounds OK). 4.1.14 and previous both digital and MIDI are fine.

I'm not sure if this will be easy. It depends. First I have to look at file sizes for those files in \4115, to see what was changed. And then I literally have to study the changed files, take my time and read them, jump between 4114 and 4115 until I understand what is happening, and hopefully see a solution. IF I find possible solution(s), then I will install a fresh DJGPP / Allegro 4.1.15, alter the source, rebuild it, and see what happens. If THIS works, then the goal will be to fix 4.22.

Also I want to look at SRC\DOS\JOYSTD.C and SRC\JOYSTICK.C, to add another joystick type that was left out of the default list (2 button 3 axis joystick, IE 2 button joystick with throttle). I looked over the code, and this one looks like it will be fairly easy.\

Use diff. It'll tell you exactly what has changed (if anything).

I don't think thats going to help... I googled 'DIFF' to see what it was and how it worked. I DID consider downloading it, but I wanted to see what I was up against first.

Using file size comparisons between 4.1.14 and 4.1.15, it looks like I need to work with DIGMID.C (maybe - to check into a possible MIDI low-volume problem) and most probably MIXER.C

I made copies of the sources from 4.1.14, 4.1.15, and 4.22, renaming them (for example) to 14MIXER.TXT, 15MIXER.TXT, 22MIXER.TXT. Copied them over via floppy to my Vista computer...

Using Notepad, opening up 14MIXER.TXT and 15MIXER.TXT and 'lining the two windows up side-by-side' on my display monitor. This makes it very easy to compare the code, actually. There is just TOO MUCH change for 'DIFF' to be of any real help. Unfortunately fixing this is not going to be a matter of changing an errant flag or a faulty define. I don't understand enough about the code's FUNCTION (theory-of-operation, and HOW this affects DOS/SBPro) to even know where to start.

Its gonna be a... 15-cup-of-coffee problem, at least.

No, you really want diff.

Even better is to learn to use Subversion. Then you can use a bisecting algorithm to figure out exactly which change caused something to break. Start by finding a revision that works and one that doesn't. Then pick a revision in the middle and check if that works, and so on. You should find the offending change within one or two cups.

You might have trouble compiling old code but as I remember, when you switch between revisions Subversion will try to keep any modifications to files you have made so you don't have to keep reapplying the same changes.

If you're willing to do try this out, I or someone else can provide the details.

Okay; I just looked over the online documentation on Delorie, and a few other sites, to understand what the output of DIFF looks like and how it could help me. I downloaded dif287b, dif287d, and documentation in the form of an ascii text file.

I've already done this (using the old fashioned brute force method);

Allegro 4.1.14 : WAV playback and MIDI playback in a DOS environment through a SoundBlaster Pro (CT-1600) sound just fine, work flawlessly.

Allegro 4.1.15 :
WAV playback is severely distorted. The volume sounds ... "EXCESSIVELY" boosted, with ... 'clipping' ... or rather, there is no envelope. Allegro SETUP -> TEST -> TEST DIGITAL sounds like a 'screech' rather than a 'gong'. All WAVS are distorted, regardless of their technical characterics. The DEMO game sounds distorted; the voice that says "Welcome to Allegro" is barely recognizable. Changing things in ALLEGRO.CFG doesn't help, I've tried all possible combinations for soundcard settings.

MIDI sounds fine, but the volume is severly depressed, and in SETUP -> (alter the volume for MIDI) it has little if any effect.

Yes, I would like to get Allegro 4.22 fixed so that I can use the latest GCC / GPP to build and use it. I don't want to settle for 4.1.14 'just because it works, yet I have to use an older version of GCC to build it'.

I think the problem is very technical. I've looked at the differences between MIXER.C for Allegro versions 4.1.14 and 4.1.15 several times this evening. I just get a headache each time. There is nothing OBVIOUS that leaps out at me, like a flag in 4.1.15 that was improperly set, or a define that was left out.

I don't understand enough of WHY instead of WHAT, otherwise I might be able to fix it.

I don't think DIFF is going to help. I can open two Notepad Windows on my (Vista) computer, compare MIXER.C from 4.1.14 and 4.1.15 side-by-side, and scroll through the two files quite easily.

I need to know what was done to 4.1.15 that would probably cause Allegro to do this to a SBPro in a DOS environment.

Doesn't diff tell you exactly which lines changed? I've done the transparent side by side log viewing before and knowing which lines are different would be nicer in my opinion. Perhaps it's not the mixer changes that broke it at all but the sound driver that changed. I wouldn't really know , but it sounds possible anyway.

Not quite. You know it's between the released versions 4.1.14 and 4.1.15. With Subversion you can narrow that down to the exact revision. In other words, the date and time that the offending change was checked in.

But it's up to you.

If you have a windows machine, I really recommend winmerge.
It can compare 2 directories at once, and for each pair of files that differs, it can show you the differences side-by-side, with colorizing.

First, I looked at the 4.1.14 sources to find files that I should check (because they might effect WAV playback). I made a list of 10 files in \SRC and \SRC\DOS. Actually I opened EVERY source file just to make certain. If it had anything to do with WAV, MIDI or sound, I listed it. This DID include the appropriate driver (SB.C). I made a note of the file sizes from 4.1.14.

Then I compared those 10 files from 4.1.14 and 4.1.15. Only two had changed; DIGMID.C and MIXER.C.

Okay - I guess I just don't understand. I downloaded and archived to CD every version of Allegro from 3.1 through 4.22, and I also ended up archiving most of DJGPP, including several versions of GCC.

So - you're saying that for 4.1.15, there is some kind of a timeline for every change? So that maybe I could try altering one change, rebuilding Allegro, and seeing if the alteration worked? You see - how do I know WHICH change is the OFFENDING change?

Version Controll is very nice like that. Code is commited to the Version Controll system every so often, and you can narrow down the problem to a specific commit to the VCS, then somoene who knows more about it can go in and fix the problem much easier (I dont think any of us have DOS boxes to mess with).

Nope. While you can, it wasn't actually suggested for YOU to fix it, just to help find it.

Jeff, I think you're on the right track anyhow: the only relevant changes in that time period are to mixer.c and digmid.c. These are the only changes to those files (excluding one trivial one):

I have attached the diffs corresponding to those changes.

Edit: yup, Chris is reading.

Unfortunately, the mixer change is a very large change, so it's difficult to tell what, if anything, in there may have broke it (I've since learned better than to make big changes like that all at once ). A look through sb.c shows that the SB Pro does stereo output no problem (thus with stereo output mode, the quality setting should not be an issue), but not 16-bit output. But I also don't see anything wrong with the internal->8-bit conversion..

I'm getting the dev forum over mail into the same mail folder as the mailing list, so yes.. and to my defense, that commit was a long long time ago - my log messages have gotten much better since (mainly because of someone nagging about it a lot over the years )

I don't remember much about the issue itself though, I guess it was discussed and tested on the mailing list before committing - but maybe not under DOS. And Chris is here anyway so hopefully it can be figured out.

Hm, one thing to narrow this down a bit without looking at the code, can someone try with another sound card under pure DOS? I assume, it's not the DOS sound as a whole which is broken, but just this particular card - but I wouldn't be sure. Wouldn't surprise me a lot if there weren't many who tried this in pure DOS in the last 5 years.

something that looks odd to me in sb.c is at line 816.

Here is a snippet starting at line 802:

Don't know though... I can't test it myself as I don't have an sb card here at the moment... anyway I'll keep looking.

Thanks all for assistance - I am just waking up, and I am on only my second cup of coffee. Cool thing about being 'retired', your time is all your own (and maybe you have a 'right' to be grouchy hehehe). For some reason I needed a lot of sleep after yesterday.

Ron Novy;
(This comment doesn't contribute much, just making an observation); It took a lot of searching to get technical specs for 'legacy' equipment. I archived general stuff for Creative Labs Soundblasters (DOS era hardware) a couple of years ago; over the past week I found 'new'(?) stuff on the web, including an archive of everything that came on floppies with the old SoundBlaster Pro (the 'SBPro Software Suite'). I found a comprehensive spec sheet on the SBPro that had not been there(?) a few years ago. I don't remember exactly where I got it, some Dell repair site. Maybe similar material exists for SB 2.0. I don't know the answer myself, all I have to go on is old experiences (from memory) with SBPro, SB16, a couple of 'Vibra' cards (Creative Labs OEM) and one ESS audio card that I had.

Elias;
(same thing); I have a legacy SB16 in the back of a closet, unfortunately I can't trust it. It was in another legacy DOS machine that I had; that machine was 'zonked' while I was in the hospital in 2001 for a heart operation (otherwise, I would have unplugged it from the wall during the thunderstorms...). All I know is that when I got home, THAT computer and my television were inoperative. BUT my 'main' (windows) computer, and everything else was OK (? - lightning - go figure! No wonder the Navajo's are so superstitious about it!). Later, I did (briefly) test it (the SB16) when I built this current 'DOS computer', but when it became apparant that the joystick no longer worked, I pulled it and put it into the closet.

Peter Wang / Kitty Cat;
Peter - thanks, I downloaded those attachments. Also copied and pasted that text from your post, and saved as a .TXT file on that floppy alongside the .diffs and my copies of three .C sources from 4114, 4115 and 422. I put them on a floppy that I have been using to transfer between two computers (this computer and my 'DOS computer'). I downloaded DIFF287 last night, and I've transfered it to the DOS machine, but haven't quite gotten around to trying it yet.

I made it easier for myself by archiving all the DJGPP ZIPs (and I think 3 or 4 versions of BNU and GCC) and several Allegro ZIPs in an archive directory on that DOS machine, so its relatively easy (by now) to rebuild everything. I will try DIFF this afternoon.

Again, thanks for the assistance - I realize that not many people still tinker around in DOS, though one person in this thread sent me a private about it (his concerns coincided with mine, he also wanted to 'fire up his P166' and try things).

Those DIFFS were from 4 years ago(?), so I guess it isn't a suprise that no DOS testers came forward (too bad, because the 'bug' is persistant through 422, its reasonable to assume its still there. Though I don't see much benefit for a DOS user to progress past Allegro 422 / DJGPP-GCC and GPP 428).

Okay - I think that the easiest thing (for me) is a brute force approach. I want to look at those DIFF files first; but maybe I can 'hack and slash' C sources from 422 to make them more like 4114 (IE undo the mixer / digmid changes) (or change C sources from 4114 to make it compatible with 422 / GCC 428).

I'm tempted to just 'drop in' the .C from 4114 into a 422 before I build it - if the changes are all/mostly internal to all/most functions, I might get very few error messages during the build.

I realize that this would be against Allegro design philosophy, but this would be along the lines of a 'personal patch', and I don't see that too many people are interested in DOS. A more elegant solution would be to test the environment and equipment, and IF DOS and IF SBPRO, than sidestep the Mixer and DigMid changes. I'm afraid that trying to determine 'why' the mixer changes are incompatible with this situation is beyond me. I know how to program, I know about the SBPro (probably more than a casual user but less than an engineer); but I can't absorb WHY the mixer changes are effecting the SBPro this way in DOS.

UPDATE:
Getting absolutely NOWHERE!

UPDATE2:
I think I am going to give up on trying to get Allegro 422 working in DOS with a SoundBlaster Pro. I only just got interested in DJGPP / Allegro a week ago, trying to reverse engineer Alleg 422 to 'fix it' is causing too many headaches.

I'm falling back to Allegro 3.12; that was apparantly the last DOS-only version, its a smaller/simpler installation, and I'll probably still have fun with it (apparantly versions earlier than that were used for 'DosDoom').

One last general question on building and using/compatibility:

Apparantly the most recent version of GCC that was compatible with Alleg 3.12 was version 2.95.3. I downloaded it.

I assume thats the same for GPP? I downloaded GPP version 2.95.3

Also downloaded Objective-C; 2.95.3; In case I might want it for some reason.
(this isn't the place to ask, I realize, but its kind of related; but if anyone wants to make a brief response - is there any advantage(s) to Objective-C? Whats the difference between this and C++?? When you do 'make install', does it also install into Obj-C, as well as GCC and GPP?)

Ok so now I am concerned about the rest of DJGPP. Logically only the compiler versions matter. I know that the lastest MAK and RHide are okay, because on a DosDoom site that offered source for the game, an Allegro version prior to 3.12 was referenced; and the referenced versions of MAK and RHide corresponded with the latest versions from the Delorie FTP site (I guess MAK and Rhide haven't changed much).

What about BNU? Will the most recent (BNU217) work? (I'm concerned because apparantly that package contains the assembler, among other things).

I think I can assume that the most recent 'File Utilities (FIL41B, I think) is ok - they are basically just a bunch of EXEs to manipulate files and directories.

What about the debugger, GDB? does that matter - with an older Allegro / GCC / GPP (BNU)?

The latest TXI should work (I hope - on the older 3.12 info file?).

Any other pitfalls I am not aware of yet with falling back to Alleg 3.12, and DJGPP?

- Thanks

I didn't dare plug my old P166 in the attic but I did check the CDs of my friend Paul Siramy, which contain the versions we used, back in 1998:

DJDEV202.ZIP    DJGPP 2.02
CSDPMI3B.ZIP    CWSDPMI
BNU281B.ZIP     binutils : as, ar, ld, strip...
GCC281B.ZIP     gcc
GDB416B.ZIP     gdb debugger
GPP2721B.ZIP    gpp (c++)
LGP271B.ZIP     c++ libraries
MAK3761B.ZIP    make
MLP105B.ZIP     djp (executable compressor)
RHIDE14B.ZIP    Robert Höhne's IDE, a must have
TXI390B.ZIP     texinfo for documentation
PAT25B.ZIP      patch, to apply diff's
BCD_102.ZIP     (library to read audio from CD's)
LIBJGMOD 0.23   (library for MOD music playing)
ALLEG30.ZIP     Allegro 3

No "major" (first digit) version difference from what you reported, so I think they stand a very serious chance to be compatible.

Thanks, Audric;

I just noticed another complication though (too complicated to get into right now). Maybe I should take a break from this for a couple of days.

Any changes to digmid are unlikely to affect playback of sound samples (it's the digital MIDI driver), so you probably only need to look at the mixer. Just thought I'd point this out.

Ok... I've been pretty bored today so I thought I'd look through some sound code... If the problem hasn't been discovered yet then here is my theory...

The SB driver is using the function _mix_some_samples from mixer.c and the function looks ok to me... So I think the problem is that the SB driver isn't setting the 'issigned' flag correctly when calling the function... From what I remember the 8-bit sample format for the sound blaster is unsigned... In the SB driver 'issigned' is being set to 'TRUE' for 8 bit sound and 16 bit sound. So if this truly is the problem there are two ways to fix it... You can program the SB to send unsigned data in 16-bit mode and set all the 'issigned' flags to 'FALSE' in SB.c or set the flag appropriately according to the number of bits being used... I think either way should work ok...

I'll be back later with some testable SB.c files...

[EDIT] Attached a modified sb.c for testing if anyone is interested...
If it works then maybe someone can make a patch...

Ron Novy;

Which version of Allegro is that from? Thanks.

I'll test it on a DOS machine once I know which version of Allegro (and thus which version of DJGPP) I need to re-install; which version(s) of Allegro I can 'drop that in to'.

(I've about given up trying to fix Alleg 4.22 myself).

I'm just thinking it should be possible to test with DOSbox.

Oh sorry... It's Allegro V4.2.2 and just for comparison the creation date on the SB.C file is 12/28/2007.

Ron;

Thanks! I'll try that out sometime today. I have to re-install the latest DJGPP, and Allegro 422... I'll drop that modified .C file in, build it, and see what happens. I'll post the results. It may be a few hours... I've been up all night working on something else.

I have to be careful with these 'experiments'. Its old, legacy hardware that I am using. That 2 Gig drive, being thrashed with I don't know how many attempts over the past couple of weeks - it couldn't have been good for it.

I started to just 'settle' for Allegro 3.12 (and an older DJGPP), but most of the tutorials that I found (including 'Vivace') were just too incompatible without heavy modification.

Thanks for trying this, I hope it works. If it doesn't, I am almost 're-energized' enough to try hacking 4.22 again.

Hey no problem... I get bored sometimes and usually have a lot of free time so I like to solve problems/puzzles and play games... But I've been up all night myself working on different things. This year I seem to be extra busy...

Anyway... I'm crossing my fingers that it works.

RON;

That modified SB.C source worked! (Allegro 4.22, DOS, Creative Labs SoundBlaster Pro). Thanks very much.

In the Allegro SETUP program, the TEST DIGITAL function resulted in an UNdistorted 'gong sound'... the way its supposed to, instead of a screech.

The PLAYSAMPLES example program plays UNdistorted WAVs now.

----

Also, its possible that a minor bug with MIDI files was fixed(?). I'm not COMPLETELY sure about this, because I was focusing on sample playback problems. But it seems to me, with a couple of Allegro 4.1.15 and 4.22 builds (several times), MIDI playback in the Allegro SETUP program via TEST MIDI had noticably low volume... I could turn up the speakers to hear MIDI, and of course digital sound playback was a lot louder (but not TOO much so). What I would call a 'minor annoyance'. Even more significant, though, was that it didn't matter what I set the volume to for OPL3; the default -1, or 255, or 10, or 128; MIDI was at a constantly somewhat-low volume.

Now with this modified SB.C of yours, MIDI output still seems to be a little low, but Allegro SETUP \ OPL3 -> change the volume; now seems to be working. I can impose changes (back and forth) between volume settings of -1 (default), 10, 50, 128, 255, 75, etc, and it behaves as you would expect.

THANKS much!

(edit)

As far as I'm concerned, Ron fixed the problem (at least for my setup). I don't see myself getting back into Windows programming any time TOO soon; I used to be very active with MSVC6 and the DirectX SDK; but with this new computer / Vista Home Premium, I see indications of bugs / problems / headaches with various compilers in several forums when the users are using Vista. Maybe 'later'.

So now I can use the latest DJGPP, Allegro 4.22; in a DOS environment on a legacy DOS machine. Yes, its pre-historic, and some people snicker (admit it - you KNOW you do), but thats OK, I can still have fun with it.

I have one more thing I want to do for Allegro 4.22; add a new joystick type. Allegro 4.22 'comes equipped' for a CH Flightstick Pro (I believe more than two buttons, plus a hat, and a throttle); I am using a CH Flightstick ('basic'?) for my DOS machine... just two buttons and a throttle.

I've studied the joystick-related sources, this looks easy to do.

Good. The fix should probably be commited to 4.2 branch and probably 4.3 as well.
I don't think there are concrete plans to release a 4.2.3, but if there are enough minor fixes I personally don't see why not (I could do the release myself if no one else has time).

Does the (more extended) Pro driver not work with your joystick as well (just identifying it incorrectly)?

EVERT;

About the joystick; yes, the CH Flightstick Pro setting DOES work; that is, the buttons (just button 1 and 2, but I think if I remember correctly the 'Pro' has 4? ... and a hat switch), the throttle, X and Y axis all work. Its just that if I select Flightstick Pro, its seems kinda ... 'weird' ... because there are 'dead' controls when Allegro 'thinks' I am using a FS Pro. No big deal... one could select FS Pro and just not bother reading the hat or extra buttons (that is if I ever complete a game project - I have ideas). There were a few joystick models (pre-usb, DOS era, etc) that had this configuration - 3 axis (X, Y, and Z or X, Y, and throttle) and only 2 buttons... just being a perfectionist, I guess; I want to add this joystick type to the list. Examining the code it seems like it will be VERY easy to do - I'll get around to it within a couple of days; I have too many 'irons in the fire' right now.

---

I might be mistaken, but I thought the 4.22 branch had been... 'closed'? Of course, the fix should probably be implemented for branches still in development; you never know when another DOS user / SBPro user will come along. Allegro is presented as being compatible for DOS, DJGPP, SBPro; so the code should be fixed. Possibly a 'Patch for DOS users' should be released on the main site for 4.22. I myself am satisfied... for the DOS machine that I have, I don't see any reason to progress past Allegro 4.22. I might be interested later in recent versions if I get back into Windows programming.

Ok, good.

Fine and yes, this shouldn't be very hard from what I remember.

There is no 4.22 branch, just a 4.2 branch. 4.2.2 is the second bug-fix release of Allegro 4.2. The 4.2 branch is closed in the sense that nothing except for bugfixes would ever come out of that branch again, and no one is particularly interested in working on it, prefering to work on newer versions of Allegro instead (which is a good thing and fair enough).
That said, if there are enough bug-fixes in the repository anyway (I think there's one or two more, of the top of my head - should check), then they might as well be released as 4.2.3.

The only relevant one is probably the 4.3 branch.

Exactly - which is why in my opinion a 4.2.3 is not out of the question.
Just to be clear, Allegro 4.9/5.0 is not presented as being DOS compatible (and it isn't).

And we can make the patched version available for download and call it Allegro 4.2.3.
It doesn't have to be much more than that.

I guess, as long as we don't release 4.4.0, 4.2.x is the latest stable branch - so a bug fix release might make sense. Of course, releasing 4.4.0 would be much nicer - all that is missing are some minor build related fixes (the only change to 4.2 is the added addons anyway), from what I remember. Still, someone with access to the right platforms has to find the time fixing them.

Oh cool... It worked! Just to be sure I haven't introduced a new bug please test it using all the different quality and bit settings... I'm in the process of moving ATM so I may not be around for a week or two to fix it but I'll at least be monitoring the forums and dev. list... But if possible, just check all bit settings etc before commiting...

We have a possiblity of severe storms this afternoon / tonight and tomorrow - when there is lightning in the neiborhood, I unplug everything.

I can do a comprehensive test on a DOS platform sometime after midnight tonight if the sky is clear... certainly within the next couple of days.

(update)

I had to get some sleep today; I just got up about an hour ago.

Weather radar shows a typical 'West Texas Monster Stormcloud" headed this way (expected for this time of year when the weather is 'moody'). It will probably hit within two hours, I can't be in the middle of an Allegro Build when that happens. It looks like things will not be consistantly calm until maybe tomorrow night. When the storm conditions pass, I WILL do a thorough test of the modified SB.C

I don't have a complete understanding of the Allegro mixer, or what to expect.. I will do a fresh install of DJGPP / Allegro 4.22. I will invoke every change / option that I can in Allegro -> SETUP, then I will invoke every change that I can in the configuration file (num bits, quality, etc). I'll test against various types of WAVs ( 8 / 16 bit, various inherant freqs, etc).

Also I'll try adding a new joystick type. It looks like I have to change only two files: JOYSTD.C, ALLDOS.H

I will just add a definition for 'CH Flightstick' before 'CH Flightstick Pro'; it will be a standard joystick, but with the JDESC_Y2_THROTTLE flag (JOYSTD.C). And I will impose the appropriate changes in ALLDOS.H

So it may be early thursday morning before I have a definitive test for you; it looks like this storm activity is supposed to die out wednsday evening (so far).

After some more testing, I can see the bug that JeffTX experienced will only happen on 8-bit SoundBlasters.
I have a SB Live 1024, which provides a legacy driver with the capabilities of a SB16 (16-bit), and can also pass as a SB Pro (8-bit) if needed.
When I run the DOS version of Allegro's setup, I can manually choose SB16 (no problem), or SBPro (screeeeech)

Now I still need to recompile Allegro with Ron's fixed sb.c, but I have no doubt it will fix the case when I rely on the SBPro driver.

The storm activity seemed to have dried up this morning (for now - next two days is supposed to be stormy).

I gave the modified SB.C driver an extensive workout.

In Allegro / SETUP, I invoked every possible combination of PAN, Quality and Frequency (the only settings that might seem relevant). No problems noted. Only really discernable difference was in the timbre of the digital test when the frequency was set to 11906 (versus the default 22727); this is expected.

Then I manually changed ALLEGRO.CFG

I used every possible combination of quality, frequency, and sound_bits (tried 8 and 16, the default was -1).

No problems noted. For confirmation, when Allegro Setup was run after forcing ALLEGRO.CFG to 11906 Hz (but skipping AUTODETECT), the timbre of the digital test was noticably changed. Forcing sound_bits to 8 and 16 did not cause any crashes, or failure of the digital test sound to play.

I copied some MIDI files and various WAV files to \ALLEGRO\EXAMPLES, as well as the ALLEGRO.CFG created by running Allegro SETUP. These WAV files included PCM 8 and 16 bit wavs, of 11025 and 22050 Hz. Invoked the EXSAMPLE program against all of these WAVs, and modified ALLEGRO.CFG for all possible settings (relevant for testing). No problems noted.

Also tested the examples -> Play Midi demo on various MIDIs, no problems. I could manually change the volume of MIDIs in Allegro SETUP, and the max volume was acceptable.

So I guess Ron's fixed SB.C can be commited.

Again, Thanks! MUCH appreciated!

-----

I also modified ALDOS.H and JOYSTD.C to add a new joystick type ("Flightstick" (not "Flightstick PRO"); a standard analogue 2 button joystick with throttle. For some reason, this new type did NOT show up in Allegro SETUP's list of joysticks when I ran it. But it DID show up in a hex editor against SETUP.EXE just before the "Flightstick PRO" entry. I'm not sure at this time, but I think I know what I missed ; there is an additional section in JOYSTD.C that I need to modify, I believe.

Awesome... I found an old Win98se disc so I'll be hooking up some of my older hardware for testing and compiling games so if there's any other problems in DOS I should be able to help out... After the move that is...

[EDIT]
I've attached some documents about the Sound Blaster and the Pro Audio Spectrum from an old sound library called 'Bells Whistles and Sound Boards' in case anyone is interested in looking them over. I made a few modifications to the SB one so it's a little more accurate than the original... When I originally started working with allegro I was using an old Pro Audio Spectrum card that later died along with the PC it was in, but I included it just in case someone wants to write a new driver for there legacy hardware...

Also I created a newer version of SB.c with some rather unimportant updates... Which I apparently forgot to take with me before unhooking my PC for the move... Anyway I wanted to test out the DSP command that retrieves the copyright string which is a feature I never knew the SB hardware had... So my newest version now modifies the description field to display DSP version and copyright string, so if I find some bigger bug/feature to fix/add later I'll send a diff to the dev list with this tacked on too.