Using Timidity possible?

[LogicDeLuxe]

I have Timidity installed on the SD card, and it plays fine in Doom. When I select Timidity in ScummVM, though, the game quits with this error:

Code: Select all

WARNING: TiMidity: connect(): Connection refused!
WARNING: TiMidity: can't open control connection (host=127.0.0.1, port=7777)!
IMuse initialization - Unknown Error!

Is Timidity actually supported? If so, how should I set it up exactly?

[DJWillis]

Is Timidity actually supported? If so, how should I set it up exactly?

In simple terms, no.

Parts of TiMidity are included in the ScummVM core codebase but the requirements to host TiMidity in-process on the GP2X are just to great to be viable. ScummVM slows to a crawl.

John

[eriktorbjorn]

Parts of TiMidity are included in the ScummVM core codebase

I thought ScummVM only included code to act as a client to a TiMidity server.

[LogicDeLuxe]

I didn't notice slowdowns in Doom, and with its 35 fps, it certainly is more demanding than those old LucasArts adventures with MIDI tracks, which only animate approximately about 10 fps.

I thought ScummVM only included code to act as a client to a TiMidity server.

Would make sense. If it's not the case, why is it?

[eriktorbjorn]

It's the Using TiMidity++ MIDI server section of the README that describes how to use it, but I don't know whether or not you can do that on the GP2X.

It doesn't work all that well even on my Linux box. The music lags behind a lot. Maybe there's some way to fix that, but since I have native support for MIDI with my soundcard, I don't have much incentive to experiment.

[LogicDeLuxe]

It's the Using TiMidity++ MIDI server section of the README that describes how to use it

It doesn't seem applicable. There is no executable in the /timidity directory. It seems to be part of the SDL code, and SDL software on the GP2X usually can play those instruments by just playing MIDI.

If ScummVM doesn't support this, how hard would it be to implement this? Sounds like merely the GM output has to be routed to SDL instead of a system specific port, right?
I can imagine that more systems would benefit from this, not just the GP2X.

[eriktorbjorn]

If ScummVM doesn't support this, how hard would it be to implement this? Sounds like merely the GM output has to be routed to SDL instead of a system specific port, right?
I can imagine that more systems would benefit from this, not just the GP2X.

I'm not sure I follow you. SDL did not have any connections to TiMidity last time I checked. (I think the SDL_mixer library contains a copy of TiMidity, but ScummVM doesn't use that.)

[DJWillis]

I didn't notice slowdowns in Doom, and with its 35 fps, it certainly is more demanding than those old LucasArts adventures with MIDI tracks, which only animate approximately about 10 fps.

I thought ScummVM only included code to act as a client to a TiMidity server.

Would make sense. If it's not the case, why is it?

Sorry eriktorbjorn, yes ScummVM just contains code for a client. I just considered that 'part' of TiMidity.

LogicDeLuxe, Why is Doom's FPS relevant to the performance of ScummVM? Having ported Doom a few times (including a 2X port) I find that statement most amusing . It has no relationship to ScummVM or any relevance to what is going on behind the scenes.

The simple answer is, if you wish to build a self contained TiMidity server and pop it on the GP2X then tell ScummVM to use it (then work around some static/dynamic linking issues with things like GetHostByName() in the TiMidity client code/gLibC, static TiMidity etc.) then it can be made to work. Considering performance is then dire I am not sure I see the benifit.

As I don't even have a working GP2X to test on it may be best to consider this very far down any TODO list from my point of view considering what other features and fixes need doing 1st.

[DJWillis]

I'm not sure I follow you. SDL did not have any connections to TiMidity last time I checked. (I think the SDL_mixer library contains a copy of TiMidity, but ScummVM doesn't use that.)

eriktorbjorn, I think LogicDeLuxe is assuming there is a link because PrBoom (the Doom port they are talking about) uses TiMidity in its SDL_mixer incarnation.

[LogicDeLuxe]

LogicDeLuxe, Why is Doom's FPS relevant to the performance of ScummVM? Having ported Doom a few times (including a 2X port) I find that statement most amusing . It has no relationship to ScummVM or any relevance to what is going on behind the scenes.

Since both use SDL, there sure is a relationship. And since the game itself doesn't have anything in common with point and click adventures, it sure is what is going on behind the scene which matters. And Timidity apparently works well with Doom on the GP2X. Also Doom is slightly more demanding on hardware than those old LucasArts adventures, so it seems reasonable to assume that those adventures would be still fast enough to be seriously playable with Timidity playing the soundtrack. Even with all reverb effects etc. disabled, it still would be better then OPL (which has no effects either).

[DJWillis]

Since both use SDL, there sure is a relationship. And since the game itself doesn't have anything in common with point and click adventures, it sure is what is going on behind the scene which matters. And Timidity apparently works well with Doom on the GP2X. Also Doom is slightly more demanding on hardware than those old LucasArts adventures, so it seems reasonable to assume that those adventures would be still fast enough to be seriously playable with Timidity playing the soundtrack. Even with all reverb effects etc. disabled, it still would be better then OPL (which has no effects either).

You can configure an X server to use SDL for video, so X11 is like ScummVM then . The GP2X port makes use of parts of the GP2X SDL library for some features but it is not a pure SDL backend.

The hardware requirements for ScummVM (a 'reimplementation' of various adventure game engines aimed at a very wide number of platforms) are completely incomparable to a port of a fixed point reimplementation of the Doom engine that has been very aggressively optemised for small platforms that lack floating point units (such as the ARM SoC in the GP2X). You should also not compare ScummVM's requirements with those of the original engine, esp. when your on a non x86 platform.

ScummVM is actually quite 'expensive' in hardware requirements in a number of areas, a compromise that is made to facilitate making maintaining, developing and understanding it much easier (and more pleasurable speaking as a developer). This is something that you have to deal with when working with a small platform like the GP2X and does lead to compromises.

You assumption that using TiMidity with ScummVM on the GP2X is viable without very extensive work both on the ScummVM GP2X backend and a suitable TiMidity server is unfortunately incorrect in this case.

I have no incentive to do the work required and as your the 1st person to raise this I assume most users are happy with the current fmOPL situation (complete with it's ear-bleeding short comings). I would need a lot more convincing that this is a real requirement before I even looked at it again, sorry.