Well, I'd prefer oprofile if I could get it working. It's a system wide profiler for Linux. It's kernel based which allows everything to be profiled without having the profile code compiled in. It uses the x86 performance counter registers. A standard linux profiler is gprof. As for windows, I suppose visual studios would suffice wouldn't it?(since you've mentioned you're using visual c).

btw, a sequencer is a midi editor/creator. You can select instruments and everything else you'd think an editor would do so if you can't find a dos midi sequencer that works, you could create the test case midi files in a windows sequencer and then play them back with whatever method you were using before.

old

1			for(t=0;t<10;t++) {
2				MidiChannel *tchan = mchan[t];
3				int ls, rs;
4
5				ts = tchan->getSample(&lsp, &rsp);
6				
7				// Spot for MMX improvement? 
8				ts = (ts * mastervolume)>>7;
9				rsp = (rsp * mastervolume)>>7;
10				lsp = (lsp * mastervolume)>>7;
11				rsp = (rsp * tchan->rightvol)>>8;
12				lsp = (lsp * tchan->leftvol)>>8;
13
14				ls = ((ts * tchan->leftvol) >> 8) + lsp;
15				rs = ((ts * tchan->rightvol) >> 8) + rsp;
16
17
18				c[0] += ls;
19				c[1] += rs;
20
21			}

new

1			for(t=0;t<10;t++) {
2                                MidiChannel *tchan = mchan[t];
3				ts = tchan->getSample(&lsp, &rsp);  
4				c[0] += ((((ts + lsp) * mastervolume)>>7) * tchan->leftvol)>>8;  
5				c[1] += ((((ts + rsp) * mastervolume)>>7) * tchan->rightvol)>>8;
6			}

btw, as far as I could tell, lsp & rsp start out uninitialized, but I don't know what they should be.

Went through the math factoring out the common variables a couple of times and when I calculated with dummy values for the variables, old & new results matched up, but it wouldn't hurt to double check my results.

A cleaned up MT32_CallBack:

1	INLINE static void MT32_CallBack(Bit8u * stream,Bit32u len) {
2		if(!isEnabled) return;
3
4		int i, t;
5		Bit16s ts, lsp, rsp, c[2], *snd;
6		snd = (Bit16s *)stream;
7
8		for(i=0;i<len;i++) {
9			c[0] = c[1] = 0;
10
11			for(t=0;t<10;t++) {
12				ts = mchan[t]->getSample(&lsp, &rsp);  
13				c[0] += ((((ts + lsp) * mastervolume)>>7) * mchan[t]->leftvol)>>8;
14				c[1] += ((((ts + rsp) * mastervolume)>>7) * mchan[t]->rightvol)>>8;
15			}
16
17			// Reverb code
18			/*
19			float tls, trs;
20			tls = ((float)c[0]);
21			trs = ((float)c[1]);
22			myReverb->run(&tls, &trs, .33);
23			c[0] = (int)(tls);
24			c[1] = (int)(trs);*/
25			
26			*snd++ = c[0];
27			*snd++ = c[1];
28		}
29	}

I dropped the assignment 'MidiChannel *tchan = mchan[t];' and referenced mchan[t] directly. If I didn't goof reading the pointer usage again, here's a link describing what that does:
http://pardus-larus.student.utwente.nl/DOC/La … ialization.html

So one, it's pointing to anywhere, and two, it's copying the contents of mchan[t] to the address pointed to by tchan. MidiChannel class holds two 65k arrays along with a bunch of other stuff.

My pointer assignment of tchan to mchan[t] is ok as mchan is an array of pointers to the 9 MidiChannel objects.

In the meantime, I've used GoldCode to profile my code. As I suspected, getSample does consume most of the time spent processing the sound (about 99%) of MT32_Callback. Interestingly though, most of that time is spent in getSample itself, not in the envelope subroutines. getAmpEnvelope is about 14% of getSample, getPitchEnvelope and getFiltEnvelope are both about 11% each. Finally, the iir_filter code consumes about 8% of the time spent in getSample. This means the other 56% of the time is spent on code within the getSample routine. The profiler claimed this is due to some of the loops within the code as they have multiple compares. This of course, is not how the real MT-32 does channel processing. Rather, it simply has 32 partials of which it assigns to channels as they are needed. I may revise my code in that direction to speed it up. (Rather than iterating though 9 channels * 6 possible poly configs * 4 partials per channel). 32 compares would have to be better than 216.