Porting modplug...?

[delt]

I was wondering, how difficult would it be to port modplug to work as a plug-in on rockbox? The current .mod support is a bit buggy/incomplete, and i'd very much like to see support for .s3m, .xm, and .it files as well. I'm willing to help with development on this.

Modplug is the best open-source option in my opinion, other than the very mangled version of modplug we're currently using in schism tracker

[Llorean]

Modplug appears to include C++, it might be a considerable amount of work. And one of the greater concerns for these formats is how to properly buffer them for use in Rockbox playback.

[delt]

DOH!! didn't think of that (c++) Yeah it does use classes, but not (much) the weird c++ syntax stuff like &variable in function headers, try {} fail {} etcetc.

But for buffering, isn't it the whole point of modplug to "convert" module files to pcm/wave data on the fly? and then send this data to an audio buffer?

[Llorean]

The module files themselves need to be buffered (be in-RAM, as you can't constantly be spinning the disk). Because module files can in some situations be too long to fit in the buffer, and because they can contain loops, there is difficulty as to how to properly manage this aspect of them: You can't loop back to an area that's no longer buffered, but sometimes you can't keep the whole song in-buffer.

Basically, non-streaming files aren't what Rockbox was designed for, and there needs to be some work in general to handle them well. This applies to MIDI as well.

[delt]

What about just keeping a copy of the module in memory, and rendering it to pcm one pattern at a time? ie. determine next pattern to play, render that while the current one is playing, and discard pcm buffers of previously played patterns, or cache them according to memory available, usage in orderlist, etc... ?

I would think rockbox's plugin architecture certainly offers enough flexibility for that. It can't be that much different from the music in a gameboy emulator.

[saratoga]

What about just keeping a copy of the module in memory, and rendering it to pcm one pattern at a time? ie. determine next pattern to play, render that while the current one is playing, and discard pcm buffers of previously played patterns, or cache them according to memory available, usage in orderlist, etc... ?

I would think rockbox's plugin architecture certainly offers enough flexibility for that. It can't be that much different from the music in a gameboy emulator.

You can do that, but it means you can't use the buffering system, and so would have to write your own.

[Llorean]

The playback system does essentially keep the original file in memory, decode to a PCM buffer, and then discard the PCM buffer as it's played.

As I think I said above, there's a significant problem when there's not enough RAM available to fit the original, compressed file. With streaming files you can dispose of played compressed data. Basically, someone needs to figure out a proper way to handle non-streaming data in the playback system.

[delt]

I still say it can be done. I mean, if you can play doom and have a gameboy emulator on rockbox - both with low latency sound - it's certainly possible to make a plugin that plays s3m and xm files. At least within the limits of the hardware it's running on. It won't be a simple matter of copy/pasting code from modplug, but it most certainly can't be that hard to do.

I'm a bit busy with other stuff these days, but i look forward to become acquainted with rockbox's source code in the relatively near future.

[GodEater]

Llorean didn't say it couldn't be done - he said it wouldn't be easy with the current design of the playback engine.

Doom and Rockboy don't use the playback engine.

[Captain Kewl]

http://www.rockbox.org/tracker/8806 -- not Modplug, but it does play other mod formats (and renders .mod more completely).

Incidentally, I did do some preliminary work on a proper Mikmod codec about a month back, but pretty much ran into the same problems as the previous attempt: the 512k codec buffer makes it impossible to render anything more than some really simple .mod files.  I attempted to hijack the file buffer and use that for memory allocation, but then that broke, well, file buffering.

[pixelma]

As far as I know, the current mod codec uses metadata-on-buffer to get rid of the codec buffer limitation, at least it plays my 2 mod files which are larger than that correctly (and I remember its first version which did not use this system and choked on the files when the "end of the buffer was reached). Maybe you can find some inspiration there?

[delt]

Looks awesome. I'll try to round up all the compiler tools to build rockbox from source tomorrow.

[GodEater]

We supply a script which does that already in svn, called rockboxdev.sh.

Or you could just download our VMWare image and use that, it has them all already installed.

[delt]

Cool. But isn't vmware commercial? (i don't have it....)

[Llorean]

It's free.