Rockbox

This is amazing. I have a ton of old Impulse Tracker songs lying around and they're playing fine. The loading time is a bit slow and could perhaps use a "Loading..." screen to let the user know it hasn't frozen. Also, the maximum volume seems a bit low, could use a bit of a boost to hear everything nicely.

On Coldfire targets, GCC seems to puke on load_mod.c. Don't we love buggy compilers?

Seems to build okay after dropping the -O flags. Sorry -- next patch I'll actually test building on other targets.

Try simulator builds too, while you're at it. There seems to be some system header mismatch here that makes it not work.

Some platform-specific defines in LibMikMod are tripping things up. I'll post a new version once I've confirmed that it builds OK on OS X too...

What's the word on building things around existing libraries of code? Problems like what we have here could be dealt with definitively by just cutting out the offending blocks, and we could probably do away with a good number of source files altogether. But I'm hesitant to make any substantial changes to anything as it's not really my code and merging any future updates to the original sources might become difficult.

Just be practical. Modifying a lib so much that merging in later changes becomes harder is of course not optimal, but sometimes it needs to be done. I also don't know how much Mikmod is maintained anymore. If future changes are small, merging is less of a concern.

* Commented out pretty much all problematic defines
* Tweaked the Makefile for Coldfire building
* Full (Mikmod internal) volume. Should fix some problems with fading.
* Increased get_more call to render 32768, which fixes stuttering in more complex files. I'm not sure if this will cause any adverse effects though -- I didn't see a value this high used in any other plugin.
* Pause uses internal Mikmod pause function. Pausing a song sounds a whole lot nicer now.

Plugging my iPod into my computer's USB port while playing a file causes the file to stop playing and then crashes the iPod when I try to exit. I'm not sure where to even begin to look.

Now compiles under r17564

This is interesting! i still have some XM's around.
only at the moment patch doesn't apply cleanly on svn, might need a resync?

Sorry about that, my bad. This should fix the messages when patching.

forgot to attach it

Ok, it compiled for my gigabeat S but had to do some small changes.
Here's a patch that i used after i patched my source with mikmod-plugin-3.zip.

It seems mikmod is running atleast at 200% of it's normal speed. sounds funny tho.

Added handling for USB plug in event. Redid the exit/quit logic and cleaned up some code too. Compiles on current SVN and has corresponding updates for key mappings.

Not sure about the Gigabeat problem as I don't know anything about it and don't have any way to test it, but first guess would be a bad value for SAMPLE_RATE in mikmod_supp.h.

Refresh display when updating info. Also added alternate displays for sample lists, instrument lists (if available), and comments (if available); toggle using Select button. Compiles under r18163.

Compiles under 18298.

And it works beautifully! :)

Is it possible to integrate this patch to show the files in the WPS?

sry the question i wanted to ask is, if it is possible to change the patch, so that the files could be shown in the WPS

Pano: I believe that part of the reason this hasn't been committed yet is that these formats would ideally be treated by a decoder rather than a plugin (whether or not that's a good reason for not accepting a patch is another discussion). But in order for something to be shown in the WPS, as you've requested, a decoder would have to be implemented.

Great patch, thank you! Still have a lot of old xm and it files so I decided to give it a try. Never applied a patch or compiled rockbox myself before, but it was very easy with the VMWare image.
Compiled under r18934 and works without problems on my Sansa c240.

I would really like to see this finally be included in the main SVN trunk, but that won't happen unless this is rewritten as a codec and cleaned up a bit.

I spent some more time recently trying to get a codec working at an acceptable level. The recent merging of the codec and malloc buffers helped, but 1 meg of ram still isn't really good for anything beyond mods and smaller s3ms.

Jason,

The new 1MB codec buffer isn't intended to stay at that size forever - the intention is to reduce it as much as possible, which will be especially important as Rockbox starts to work on new targets, some of which only have 1MB or 2MB RAM in total.

I know almost nothing about the formats mikmod plays, but looking briefly at the source code, I see that it supports about 18 different file formats - are these 18 different codecs, or just different ways to store the same thing?

You mention in the first comment that you've only tested four formats - MOD, S3M, IT, and XM. How much of the code is shared between these formats? I'm wondering if (with some build-system magic) it would make sense to build separate codecs for each format? This would minimise the codec size, and also give more scope for optimisation (e.g. IRAM usage).

But even that won't solve the main issue of memory usage. Do you know how much memory each of the four main formats requires? Ideally, codecs like this should use the main audio buffer as working memory, which means the buffering API would need changing to meet the needs of these kinds of codecs. The first step towards this would be to try and define this API - i.e. what memory is needed?

It may be easier to discuss this on IRC.

Compiles under r19176.