I was wondering if your driver could be made SMP aware and take advantage of a second CPU. I do not know how much work this would be. Maybe not enough people have duel systems to make it worth while, but there are now the P4s with Hyperthreading that can benefit from SMP aware apps.

Creative Labs did not make SMP friendly drivers untill they had to when Hyperthreading came out and they knew that it was going to be more of an issue as more people would have one of their cards in a Hyperthreaded system than in a true SMP system.

This might help with the high resource demands of the driver and leave more for DOSBox.

It's not so much SMP aware as multi-threaded. A single threaded processing loop cannot benefit from SMP or SMP-like features such as HT.

EDIT: Now, it would mean better multitasking... ie. the driver executes on one processor while the game and/or emulator execute on the other. That should not require any changes to the driver or emulator.

An emulator would have to be split into multiple processing threads to take advantage of SMP. The only emulator I know of that really does this is BasiliskII... Perhaps there is also UAE, but I haven't used that for over a year, so I've forgotten if it had a thread priority configuration dialog.

This driver parses MIDI events and renders audio in real-time. I don't really think there's much that can be offloaded into other threads. Do feel free to point out where I'm wrong, so someone can get to implementing the feature.

(Funny, slightly off-topic comment. I develop components for an audio player called Foobar2000, and I follow its forum on a regular basis. Anyway, this one developer seemed to think that the player executed each step of the playback chain in a separate thread. Audio decoder in one thread, DSP chain in another, output in the final thread. Nope. The whole playback loop is a single thread. Turning something like that into multiple threads is just too much of a mess. Then you have a pile of threads looping and waiting for input, then processing, then waiting until the threads that handle their output are ready to receive the data, etc.)

My response to the poll:
I'd have to say it's a toss-up between Sierra and Lucasarts. Sierra really pushed the MT-32 back in the day (before the Adlib even existed, let alone the Soundblaster). As part of that, they made high-quality music especially for the MT-32 for their early SCI games as well as other games like their Japanese imports (Sorcerian, Zeliard, Firehawk, etc.).

Lucasarts also gave a lot of attention to the MT-32 music in their games (Monkey Island, Loom, etc.). From what I understand, they were very proud of the technology they had developed to allow the music to change in reaction to what was happening (using transitional music to segue between songs or something).

(unfortunately?) By the time I got into soundcards, the Sound Canvas and Soundblaster Pro were all the rage and the MT-32 was losing popularity among game developers.

kode54 wrote:

Now, it would mean better multitasking... ie. the driver executes on one processor while the game and/or emulator execute on the other. That should not require any changes to the driver or emulator.

Of course you are right, so maybe somewhere on the dirver's property sheet there could be a place to set the driver's processor affinity. I know that you can set it manually from the Task Manager, you would have to do it every time.

I find that although Sierra knew best how to take advantage of the MT-32 (custom sounds, etc) I am not a fan of their music (read: melodically) which I find lame. I much prefer Lucas, and even better, Origin Ent. (Gateway I/II, Eric the Unready, etc, right?)

HunterZ wrote:

My response to the poll:
I'd have to say it's a toss-up between Sierra and Lucasarts.

The Adlib and MT-32 were both released in late 1987. The Adlib in August, and the MT-32 I'm unsure of except late 87' prior to September. The first revision of the MT-32 manual(1.01) was in September, which leaves July or August but I'm pretty sure it was also released in August. Sound Blaster was released November 89' and SB pro in May of 91'.

HunterZ wrote:

From what I understand, they were very proud of the technology they had developed to allow the music to change in reaction to what was happening (using transitional music to segue between songs or something).

The name is iMuse 😀
http://imuse.mixnmojo.com/what.shtml

Origin made the Ultima and Wing Commander games, Gateways and Eric the Unready were made by Legend.

DjLc wrote:

The name is iMuse 😀
http://imuse.mixnmojo.com/what.shtml

Ah, yes thanks - I couldn't remember the name but I knew it had one 😁

ih8registrations: Thanks for the background info. I wasn't into sound cards or synths back then, so I was only dimly aware of what was going on at the time.

vladr: I do remember liking more songs from Lucasarts games like Monkey Island 2 than from most Sierra games, although I also remember liking the music from games like Betrayal at Krondor quite a bit. Of course, I've never heard a real MT-32 that I know of, so I can't judge the actual MT-32 soundtracks to those old games.

Ok, I started a simple program to do the ALSA playback. Initially everything seems to work ok; however, in testing, I don't feel like parsing the midi file to get the raw data from it. Does anyone know of a program that will play a midi file to output to a file that has only the raw sequencer data? I checked playmidi, pmidi, tse3play, and timidity....

BTW, my approach is, instead of creating a different mt32-server for this, I want to implement it as a timidity backend, so that it can be used with either standalone timidity or timidity with the server frontend.

Have you posted your source code anywhere? If I could take a look at it I may be able to help you more. Also, you don't want a file with just raw sequencer data. The important thing about MID files is that they contain both the raw sequencer data and the delta time references for when to send the MIDI commands. Without the delta time queues your MIDI playback would be seriously out of tempo.

Oh, the tempo really doesn't matter -- I just want to get some sound from it 😉

main.cpp

I've had to hack and rehack it so there are probably some braindead things at the moment.

Maybe I'm understanding you wrong, but have you just done, like, "cat file.midi > /dev/sequencer" (or whatever the midi device is)

ALSA doesn't use device nodes. Anyway, I'm not trying to output to an ALSA sequencer, I'm wanting to output the emulated MT-32 to an ALSA PCM device. However, I don't want to write a sequencer code myself, which is why I was looking for the program to play a midi file to a file with the raw sequencer data.

Thinking about it, I said that wrong. What I meant to say is that ALSA does not use device nodes as its API like OSS does. Anyway, it is mostly irrelevant since I will be using timidity's existing features to actually output the sound; the MT32 emulator will simply be glued in between the timidity sequencer and the final output (where the GM MIDI engine currently is).

runderwo wrote:

Oh, the tempo really doesn't matter -- I just want to get some sound from it 😉

main.cpp

I've had to hack and rehack it so there are probably some braindead things at the moment.

K... I posted the core MT-32 emulation source code on my site. I've documented the header file (like I should have done all along) and it also contains a few optimizations. Its still not ready for a new release. One thing though, the MT-32 callback function takes its length in samples, not bytes. Of course, without my proper documentation you wouldn't have known that, hence the documented header file. Hope this helps.

Thanks, I don't plan on "releasing" anything soon; basically right now I need to first get it playing something, then I'll look at how much restructuring timidity needs to shoehorn the MT32 engine into it. Unfortunately timidity is a C project so we may end up needing a C interface to the emulator.

Cool, I can now play /dev/urandom and hear noises from the emulator (before it goes silent from abuse) 😀
Now the question is, how to go about testing this thing. I still haven't found a program that will dump me some nice raw midi data. I tried /dev/midi while I play on my keyboard, but nothing seemed to happen

For testing purposes, attach a file produced through cat /dev/midi > output.raw so I can see what its producing in the way of MIDI commands.