Thanks so very much for you help in porting this to linux. I'm about ready for another release. Tweaking the sound is really getting quite hard at this point as its just now slightly out of tune. I'm going to post my latest source here (with considerations made for your port) ASAP so you can integrate it with what you've done. Thanks again!

I've posted the most recent source code on my site. Do you mind if I post your port to my site?

Any chance of a more final release of the Windows driver? The download page has it greyed (highlighting its age in comparison to DOSBox) - is this still the case?

Thanks in advance!

I have converted the Linux port to the latest version of the emulator from
the Dosbox source. It was a bit delayed due to the mystery of the missing pianos. A regeneration of the waveforms.raw file solved that problem but I wasted a lot of time looking for a cross platform incompatability. I have smoothed out some of the rough edges from the first release including some documentation and a command line switch for the reverb. This second release is a much larger package because it also contains a new copy of the waveforms.raw file.

This latest version of the MT-32 emulator has a really good sound so congrats to all who were involved(I am guessing Canadacow and please feel free to add it to your site).

The latest version can be downloaded from http://adam.rau.ac.za/~td/mt32-2-11.tgz

Yeah, I plan to release a new Windows driver the moment I get a chance.

Tristan wrote:

...it also contains a new copy of the waveforms.raw file.

I haven't played with either Windows or Linux version of the MT32 emulator much yet. What does the waveforms.raw file do?

Sorry about the long time for a response. The waveforms.raw file contains pre-computed information so that it does not have to be recalculated everytime the program is started. As the name suggests it contains waveforms, sin and cos functions over a range. Trig functions are expensive so it is worth the effort. At least that is how I understand it.

Yes, that's correct. I could generate the waveforms on the fly, but they have to be bandlimited to prevent aliasing. There really isn't a fast way to do this... As such, I just generate the entire scale of notes possible before starting the emulation.

Sorry for the slow reply on my part too. Been really busy recently.

Thanks, guys.

I was experementing with the SSE iir_filter code comparing its performace to the standard C code version. I extracted the relevent code for both functions and found that the C code version is much faster. I have posted the results below. The numbers
are the number of seconds taken to complete the test.

Pentium 4-Celeron, 1.8 Ghz
C code time 25 seconds
SSE code time 51 seconds

Pentium 3, 550 Mhz
C code time 32 seconds
SSE code time 104 seconds

I don't know if this is just something strange and particular to my setup or if it is a general issue but the difference is quite drastic.

Anybody finding that the SSE versions are slow?

Do you have the source code that you used for your benchmark? I ran a similar benchmark and here are the results I got:

Celeron 1.33Ghz
C code: 63 seconds
SSE code: 61 seconds

Athlon T-Bird 1.4Ghz
C code: 58 seconds
3DNow: 51 seconds

While not blindingly fast, these averages do perform at the normally expected 3-15% improvement over the non-SIMD versions. My first guess is that you fed the filters near 0 values (but not zero values, because then you trip the early out features of the floating point math.. in that case, the 3DNow and SSE versions leave the FPU versions in the dust). With extremely small numbers (denormals), the CPU has to invest extra math to maintain precision. This slows down the CPU. In any event, I was unable to match your results. Here's the code I used to bench the filters:

1	// Benchmark 3DNow, Floating point, and SSE filters
2
3	Bit32u bench;
4	__time64_t start, end;
5	float histval[50];
6
7	_time64(&start);
8	for(bench=0;bench<200000000;bench++) {
9		iir_filter_normal((float)rand()/(float)RAND_MAX,&histval[0],filtcoeff[rand() % 200][0],0);
10	}
11	_time64(&end);
12	LOG_MSG("Bench completed in %ld seconds", end - start);

Of course, I replaced the filter function with the respective version to test each. I ran each 5 times and got the same result nearly every time.

You hit the nail on the head. I seeded with fairly small values to avoid the potential of overflow as I an not familiar with the algorithm that iir_filter implements. As you pointed out I avoided zero values. I extracted the two functions from the main program in two a new program to peform the test.

I guess most of the time is being taken by the multiplication. I was not under the impression that near zero values would affect multiplication in this way. If anything I would have thought that the number of on-bits in the multipliers mantissa would have had a greater effect.

I changed my program segment to use larger values and got similar results as to those you posted (weeded out a minor bug in the Linux version of the SSE code at the same time).

Well I learned something new. Sorry for wasting you time.

Well, I'm glad someone finally did this. Lord knows I spent enough time on it. 😀 I could never get it fast enough to emulate in realtime. That was before the lawsuit though so the code is probably in much better shape now.