MIDI support not working?

[DivideByZer0]

I was trying to play some MIDIs on XBMC, which according to the wiki should support it, but nothing would happen when I selected the file to play it. In the debugger, it appeared to be failing inside the timidity library. I saw mention on the forum of a version of XBMC that does support MIDI playback: viewtopic.php?t=1632 but was unable to find this version.

I tested the current version of XBMC, and XBMC 3.0 and neither of those worked. XBMC 2.0 didn't have MIDI support, so I assume it was added sometime between versions 2.0 and 3.0.

I also noticed in the XBMC source that the Timidity is looking for either a timidity.cfg or a soundfont.sf2 in system/players/paplayer/timidity. I didn't find these files in any version of XBMC, and the sound font I tested didn't work, but the code suggests that it should be satisfied with only a sound font. If it were set up with the correct configuration, maybe it would work?

Has anyone gotten MIDI files to play through XBMC? The ability to change sound fonts seems like a really cool feature, and maybe MIDIs are slightly less uncool than they were 10 years ago

I did find these, which was easier to browse than SVN: https://github.com/rkalz/xbmc4xbox/ https://github.com/xbmc/xbmc-antiquated/ It looks like there was an earlier version of the timidity DLL, which was later replaced... time to start building versions!

[DivideByZer0]

Alright, I figured it out! But there is one problem... there seems to be a memory leak in the current version of timidity.dll (used to play midi), and sound fonts didn't seem to be working with the old version. So, here is the old timidity.dll: https://mega.nz/file/SENSkIpa#G6DEWiKO1 ... xqYsiBMYNI

Download this, and replace [your xbmc folder]\system\players\paplayer\timidity.dll with this one. Rename the old one to something like timidity.dll.orig

To provide instrument sounds (required), you can use the GUS eawpatches set: https://mega.nz/file/PNdRUJjK#A8qcDDO5- ... AJYwNe317s

Just follow the instructions provided in the zip. I've edited the paths in timidity.cfg for XBMC, this seems to be enough to get it to work. This set may have been distributed with the T3CH builds? Only the patch files needed for each song are loaded into memory.

Other patch sets should be able to have their paths renamed similarly to work this way.

Note that these were cranking the CPU using the new version of the DLL (the one with the memory leak, ~500Kb). They work fine with the old DLL provided above (60Kb). The old version of the DLL was all around much kinder on the CPU.

It still didn't display the lyrics with the single karaoke MIDI track I tried, but I doubt too many people are losing sleep over that.



USING A SOUND FONT (only works with current memory leak version, doesn't work with the stable dll above)

1. Create a new folder, in [your XBMC directory]\system\players\paplayer\timidity
2. In this new folder, create a file called timidity.cfg with the contents:

Code: Select all

soundfont Q:\system\players\paplayer\timidity\soundfont.sf2

3. Copy the sound font of your choice to the same folder, and name it soundfont.sf2. (like this one: https://www.doomworld.com/forum/topic/1 ... soundfont/ ) Note that the sound font must be called soundfont.sf2 for it to work.

Watch out for sound font sizes, <10 megs is probably good. I haven't tested it on a stock Xbox. I was getting memory warnings on a 128Mb Xbox, using a 40Mb sound font with Milkdrop running. What it should be doing, is only loading the needed data into memory from the sound font, and it doesn't look like that's what's happening. But, performance was better on this non working (or non properly managed) version of the DLL than with using the patch set above.

[Dan Dar3]

@DivideByZer0
Nicely explanations and the steps provided (Y)

Yes, it is possible for the XBMC4Xbox T3CH builds to contain more files which may be copyrighted like soundfonts you mentioned - the project here only contains the base open-source code.

I'm not familiar with the MIDI part area, I just found the wiki section on our site on how to "enable MIDI playback" (seems to be the original copy, I will update it with the more common Q: paths like you used too), an that is by providing a default sound file (`Q:\system\players\paplayer\timidity\soundfont.sf2`) or by crafting a `Q:\system\players\paplayer\timidity\timidity.cfg` file to point to one.
https://www.xbmc4xbox.org.uk/wiki/HOW-T ... I_playback

MIDI playback

There are two ways to configure embedded Timidity synthesizer and enable MIDI playback - a simple way, and a more advanced way.

Simple way, you need a single soundfont file. Those are typically large (50Mb+) files with .sf2 extension, the most popular resource is http://www.sf2midi.com I recommend using widespread and well-tested SGM-180 soundfont, google for it or get 2.01 version from http://www.geocities.jp/shansoundfont/ (this one is included into Arch linux in the soundfont-sgm180 package). Download the file, rename it to soundfont.sf2 and put it into your XBMC Media Center system directory (not your home directory) into system/players/paplayer/timidity subdirectory (you must create it first).

Advanced way, you need to prepare timidity.cfg configuration file. Usually this is necessary when you use multiple soundfonts or want to add post-processing effects. This means you know enough of Timidity, and could handle it yourself. XBMC Media Center embeds version 2.13 of Timidity. Create timidity.cfg and put it in the system/players/paplayer/timidity subdirectory, and check XBMC Media Center log file for errors if it doesn't work.

Please note that for SGM-180 soundfont playback you need a decent machine with at least 256Mb of RAM and at least Pentium 2.4GHz CPU. Otherwise get a smaller soundfont.

The initialization code seems to be require at least one of them, which makes sense now with your findings too:
https://redmine.exotica.org.uk/projects ... c.cpp#L115

Code: Select all

static const char * DEFAULT_SOUNDFONT_FILE = "special://xbmc/system/players/paplayer/timidity/soundfont.sf2";

bool TimidityCodec::CanInit()
{
  return XFILE::CFile::Exists("special://xbmc/system/players/paplayer/timidity/timidity.cfg")
	|| XFILE::CFile::Exists( DEFAULT_SOUNDFONT_FILE );
}

[DivideByZer0]

@DivideByZer0
The initialization code seems to be require at least one of them, which makes sense now with your findings too:
https://redmine.exotica.org.uk/projects ... c.cpp#L115

Code: Select all

static const char * DEFAULT_SOUNDFONT_FILE = "special://xbmc/system/players/paplayer/timidity/soundfont.sf2";

bool TimidityCodec::CanInit()
{
  return XFILE::CFile::Exists("special://xbmc/system/players/paplayer/timidity/timidity.cfg")
	|| XFILE::CFile::Exists( DEFAULT_SOUNDFONT_FILE );
}

This had threw me off: Although the XBMC source code looks for a timidity.cfg file and/or a soundfont, it appears that timidity.dll is expecting a timidity.cfg even if a soundfont is provided. (Either that or perhaps the XBMC code or the wrapper code inside the DLL are not setting up timidity right for use without the config file.)

I noticed using dependency walker that there was a new cleanup function in the current DLL, DLL_Cleanup (with no arguments or return type that I know of) that wasn't being called. Adding this function in TimidityCodec.c, TimidityCodec.h, and DllTimidity.h, and calling it here seems to work.

EDITED (so that it gets cleaned up on failure to load a file):

Code: Select all

void TimidityCodec::DeInit()
{
  if (m_mid) {
    m_dll.FreeMID(m_mid); 	
  }
  if (m_loader) {
    m_dll.Cleanup();
    delete m_loader;
  }
  m_mid = 0;
}

There's no memory leak, and it can play sound fonts pretty well. But there is one last problem... When a song completes and the next song starts up, it seems to "preload" the new song, which is causing crashes occasionally (i think). I'm able to hit "next" and "previous" track with no issues (i assume because there is no preloading here), but under 5 seconds from track completion it seems to crash sometimes.

[DivideByZer0]

The issue appears to be due to simultaneous access to the sound font. A few seconds before the end of a song, it will attempt to create a player. This also will load the sound font from disk, which fails because it is still in use by the previous instance of the player, which is still playing. It also occasionally causes the DLL to crash. (or, the previous instance attempts to re-access the sound font while it's in use.) However when it doesn't crash, a new player is successfully created at the time playback is supposed to start, so it looks like it's not too far off.

Also, if the creation of the overlapping player were to succeed, that would mean the same sound font would be loaded into memory twice, which would be a problem for stock Xboxes, and it can cause performance issues with song playback.

I guess the issue is that MIDI playback is unique in that by using sample/patch files to play back audio, it needs to load a significant amount of data into memory. (even though this DLL is probably loading more than it needs) So it would need some kind of unique handling in terms of simultaneous loading of players. (Or, the same player could just be reused in this case; it takes some time to reload the same sound font from disk on each song)

I was looking into building the current version of Timidity from source. The old 60kb version definitely doesn't have Soundfont support, and it's a Visual Studio project. The current source used in XBMC is a makefile project using autoconf and I was able to get it to configure and attempt to build in mingw32. However there is no makefile for the "timidity" source folder, which the make process chokes on; the core source files in the DLL simply don't get compiled. There is a Makefile.win32.in I believe that seems to serve this purpose, but I'm unsure how to build the project as a whole with it, since none of the files seem to make any reference to it. I need to look more into how building the libraries for win32 works, since this is fairly obscure

[Dan Dar3]

To be honest I would suggest raising a ticket in Redmine where to mention your findings and ask Buzz. I see he's active again and he might be able to tell you what he knows and help you with updating and building the new sources.

https://redmine.exotica.org.uk/projects ... acker_id=1

From the little I know about that area and from what you are saying, if the MIDI player de-inits properly first before starting a new one and that would probably fix your problem. Or maybe there shouldn't be a new player created and should just receive all those files as a list in the first place, but maybe it's not that start and that's why the solution to create a player every time with just one song because that's what it supports in the first place.

[DivideByZer0]

Thanks, I wasn't sure if there was any work being done on xbmc4xbox anymore, glad to hear that it's still active!

I think that the DLL should be able to support playing files sequentially, if the code controlling it were set up to do that. It would just have to call FreeMID at the end of the song, and then load a new MIDI. This would be ideal, because then the sound font wouldn't have to be reloaded from disk for each song (which can take a couple seconds.) I might try to implement it first in the next few days when I get the time, since I'm already this deep into it