Opened 17 years ago

Closed 17 years ago

Last modified 6 years ago

#8731 closed patch

Add TiMidity++ MIDI server support

Reported by: SF/amdmi3 Owned by: fingolfin
Priority: normal Component: Audio: MT32
Version: Keywords:
Cc: Game:


TiMidity++ can work as MIDI server listening on TCP socket, and can thus provide pretty good music quality on many platforms. Especially useful where there's no native sequencer at all (FreeBSD, for example) - timidity provides much better quality than Adlib emulation.

Ticket imported from: #1815526. Ticket imported from: patches/836.

Attachments (1)

scummvm-timidity.patch (20.4 KB ) - added by SF/amdmi3 17 years ago.
Updated patch

Download all attachments as: .zip

Change History (14)

comment:1 by SF/amdmi3, 17 years ago

A bit updated version: remove #ifdef(UNIX) in sound/mididrv.cpp (just forgot to remove it - timidity support should be available on all systems) and move timitidy to softsynths group, where it belongs better. File Added: scummvm-timidity.patch

comment:2 by eriktorbjorn, 17 years ago

Since there is some overlapp in functionality between this and the FluidSynth music driver, it would be interesting to compare the two. (I'm not arguing for or against the patch here.)

I know that TiMidity traditionally used "GUS patches" for its instruments, while FluidSynth uses a SoundFont. (TiMidity++ can use either.) From what I understand, both have their advantages and disadvantages. I imagine TiMidity (with GUS patches) needs less CPU than FluidSynth, for one thing.

I know FluidSynth has problems with the very beginning of Day of the Tentacle. I don't know whether or not TiMidity has any such problems. I probably should report that as a bug to the FluidSynth developers (as I recall it, the same bug happens when hooking up FluidSynth through ALSA, so I don't think it's a bug on our side), but I never bothered subscribing to their mailing list.

FluidSynth offers a programming library, so it doesn't have to be run as a server. I assume this might make it a more portable solution. On the other hand, I never did manage to get FluidSynth to compile under MinGW...

Any other thoughts?

comment:3 by SF/amdmi3, 17 years ago

I actually don't know much about MIDI synthesizers/soundfont stuff. It just happened that there weren't any quality MIDI support (except AdLib) in FreeBSD port of ScummVM, and an acquaintance of mine asked to help with adding TiMidity support, so I spent some time and came out with this patch. Then I discovered that there was FluidSynth support, and also modified ScummVM port so FluidSynth could be enabled (this was committed yesterday), see

Thus, I can't actually compare quality and features of FluidSynth and TiMidity, but I was told that TiMidity is better, but it eats much more CPU than FluidSynth.

It's true that functionality of both MIDI synths overlap, but still they work differently and each has it's own advantages (I mean technical, i.e. not taking quality into account). I don't think TiMidity is less portable as FluidSynth, as the server can by run everywhere, and client-side socket code is pretty simple, so this should work everywhere ScummVM can be compiled on. If you say there are problems with FluidSynth in specific environments, TiMidity may be used instead (at least, it shouldn't have any problems with MinGW).

This all can be of course tested, and also I can ask a guy who made me write this patch more on quality differences.

comment:4 by fingolfin, 17 years ago

Owner: set to Kirben

comment:5 by fingolfin, 17 years ago

"and client-side socket code is pretty simple, so this should work everywhere ScummVM can be compiled on. "

well, everywhere *sockets* exist, which is not everywhere, which makes this less portable :-)

Anyway, I think it would be a good idea to integerate this. But I wonder if it compiles e.g. on Windows, or on other ports. Maybe we have to deactive the code on non-UNIX systems via a corresponding #ifdef...

Kirben, does this patch compile (or even "work" in some meaningful way) on Windows?

comment:6 by SF/amdmi3, 17 years ago

> well, everywhere *sockets* exist, which is not everywhere, which makes this less portable :-)

Hmm, can't imagine a platform which runs scummvm, but lacks sockets :) If such platform exists, surely #ifdef, but as far as I remember, Windows supports POSIX enough for simple socket code (though I didn't try). Anyway, if it does not compile/work, I'll be happy to try to fix it.

comment:7 by Kirben, 17 years ago

The updated patch, doesn't compile under mingw, so making code optional would be best.

Windows doesn't have any support for POSIX style sockets, the network code would need to be re-written for Windows.

by SF/amdmi3, 17 years ago

Attachment: scummvm-timidity.patch added

Updated patch

comment:8 by SF/amdmi3, 17 years ago

Actually there is POSIX socket support in Win32 ( You could try to add #define "winsock2.h"

But I'm not sure about other functions used like getenv(), and I lack any ability to compile this on Windows, so I guess #if defined (UNIX) is needed after all. Updated patch attached. File Added: scummvm-timidity.patch

comment:9 by fingolfin, 17 years ago

Well, you may not be able to imagine them, but they exist: Nintendo DS, PalmOS, Playstation 2, Playstation Portable, and more.

comment:10 by bluegr, 17 years ago

A user has posted a tutorial on how to get Timidity working under Windows (without sockets, using the Windows MIDI music driver) here:

comment:11 by fingolfin, 17 years ago

Owner: changed from Kirben to fingolfin
Status: newclosed

comment:12 by fingolfin, 17 years ago

Since the driver now is proteted by an #ifdef UNIX, I commited this. Thanks for the contribution!

comment:13 by digitall, 6 years ago

Component: Audio: MT32
Note: See TracTickets for help on using tickets.