• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Plugins
  • Assigned To No-one
  • Operating System iPod 5G
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by captainkewl - 2008-03-26
Last edited by fg - 2010-12-12

FS#8806 - MikMod MOD, S3M, IT, XM player

Player for various tracker module formats supported by MikMod 3.1.12 –

* All MikMod-supported formats should be playable in theory, though viewers.config is set to recognize only MOD, S3M, IT, and XM. Those four formats are the only ones tested.
* Only tested on iPod 5G. Realtime playback on most mods; some stuttering on more complex IT files like
* Had to butcher libmikmod a good bit to get it to compile. As has been noted elsewhere (, there are colliding namespaces (BOOL, nop) and undefined types (FILE).
* Based on midiplay by Karl Kurbjun
* dbestfit malloc() replacement by Daniel Stenberg

Closed by  fg
2010-12-12 15:05
Reason for closing:  Accepted
Additional comments about closing:  

Committed the plugin version as r28810.
If the codec version is still wanted, please resubmit as a separate task.

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

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! :)

pano commented on 2008-09-15 11:54

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

pano commented on 2008-09-15 21:02

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.


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.

Here’s what I have so far for a codec. Right now it only has drivers built in for MOD, S3M, XM and IT. Malloc with the files I’ve tested consumes up to 4MB (though I’m sure in some cases it will go well beyond); playback works comfortably with CODEC_BUFFER increased accordingly.

Works beautifully on my Gigabeat S here, save for one tiny niggling issue:

On occasion, when refilling the buffer, the music playback will briefly pause for about a second before resuming.

Nice! works good on my Gigabeat S too.
Also i have some tiny issues when refilling the buffer.

Plays fine, how about tags?

Plays very nicely on my iPod video as well.

Updated plugin to build under r19747. New features:

* now uses WPS keymappings
* select previous/next track in current directory
* menu to toggle CPU boosting and a few interesting if not really useful playback settings

Regardless of how the codec goes, I think a plugin is still worthwhile, as it provides features that don’t really work in a WPS, like comments and instrument/sample listings.

“Regardless of how the codec goes, I think a plugin is still worthwhile, as it provides features that don’t really work in a WPS, like comments and instrument/sample listings.”

Definitely agreed here. Dare I say the WPS feels cumbersome for chiptunes?

On my sansa e260 I can only get mods to play. I’ve tried several revisions and I can’t get anything else but mods to work.

Pjstaab: sounds like it’s not even being used; mods are already supported as a codec. With the exception of the patch posted on 9 December, these are all viewers. Are you sure it’s compiled in, and that are you opening the files through the File browser?

Builds under r19793.

Well I tried patching it several times and I kept getting erros on subdir but I finally got it now when I go to compile it freaks out. Something about overriding commands for target and redefinition and previous definition.

Well I tried it again and it worked.

Maybe not.

Yeah, I can’t get it to work. I got the codec to work fine right away when you put that out but I haven’t been able to get any of the patches to work.

I patch cleanly to minimize hassle; i.e., when a new version of the patch is posted, I delete my copy of SVN and start over. Then again, this (Mikmod) is the only patch I use right now. :)

With that said, I am able to apply the patch without any problems, but of course your mileage varies. :)

I’ve tried that, getting a fresh copy of SVN and I run no other patches. It’s just really weird since I used the codec without a hitch.

I solved my problem. Before I would always get a hunk failed at SUBDIRS so I would manually add that line, but it still didn’t work. Turns out the first thing to be patched, viewers.config, doesn’t patch either, but would always go by too fast for me to notice. I manually add SUBDIRS and viewers.config and now it works beautifully.

Works like a charm =]

Quick-Fix mikmod CODEC patch to compile again with recent SVN.

cool so where’s the file that i just copy into my rockbox installation and it works? thx

mud commented on 2009-02-27 04:54

@jasonmog: That’s not how patches work. You need to be able to compile and build rockbox yourself, and then you can apply and use patches (such as this one). Here is some information to get you started: .

I hope this patch hasn’t died. The plugin, at least, seems to work astoundingly well. Surely it could be committed?

mikmod_codec.patch applied cleanly to r20681. When compiling gcc alerted me to a bug:
mikmod.c: In function ‘codec_main’:
mikmod.c:119: warning: comparison between pointer and integer
Line 119 is “quit = samples < BUF_SIZE” which certainly seems wrong. Samples is a pointer to the buffer and BUF_SIZE is its size. As a result, quit is always false. This doesn’t seem to lead to problems because Player_Active() causes that loop to end.

Now I’m listening to some IT, S3M, MOD and XM files on my 5G 30GB iPod. Some files just result in a codec failure, some files result in what seem like underruns, the interface is sometimes unresponsive, and the progress bar never behaves correctly. However, the majority of files play and sound very good.

If these problems can be cleared up and fixed, then I think it’s safe to say commit it.

The codec patch is working fine on my Gigabeast, also applied to r20681. I’m not getting the unresponsive interface issue, but the progress bar does act very strange sometimes.

The MOD player which currently in SVN has the same progress bar issues. In both cases, the problem is that the metadata parser returns a hardcoded length instead of checking the file, and then ci→set_elapsed sets a value based on the current pattern in the mod instead of the current time.

The MOD player in SVN has a serious problem which this codec does not: I’ve never seen it move on to the next track. It just keeps repeating the same track, and “Repeat One” is not set. The only way out of the while (1) loop in apps/codecs/mod.c in SVN is (ci→stop_codec || ci→new_track). So, this patch is already better than what’s currently in SVN.

Does anyone know of any MOD metadata code which is licensed under the GPL? I was looking at a few different MikMod plugins for other software, and I didn’t see proper metadata reading anywhere. It seems MOD doesn’t have a convenient length field; one has to go through the whole file and calculate length based on the number of patterns.

I think what you’ve found is pretty much it – there is no length-related metadata; and really the length could be anything, depending on how loops are handled. I believe the Mikmod method of determining length and scrubbing by time involves iterating through all patterns from the beginning while using null ouput and keeping track of elapsed time. One could perhaps perform this at loading time and build some kind of index.

The performance issues are due to buffer underruns and the general performance hit of mixing samples on the fly… could possibly use separate threads to keep the buffer full.

The codec failures are due to a lack of memory. If you’re serious about committing this, cutting out support for everything except MOD support might be the way to go, as anything more complex than that stands a good chance of not loading (unless someone can figure out how to exploit the audio buffer). I think we can add this to the list of reasons why Mikmod as a separate plugin would be worthwhile.

ep0ch commented on 2009-04-15 16:05

cutting out everything but MOD support kinda defeats the purpose of this patch…

What does VLC Media Player do to figure out the length? Just a thought….

And please don’t kill support for the other formats, if at all possible. May I suggest at least keeping the plugin for those?

Addendum: Just updated and compiled for the first time in a while. The only patch applied is the plugin (revision 9). Building is successful, but trying to load Mikmod gives an “incompatible version” error.

xqwyz commented on 2009-05-07 15:10

The “mikmod_codec.patch” did work for me. I used the current SVN (revision 20866). Had to do the changes in “/apps/codecs/SOURCES” manually because the file differs. But then it compiles without errors and runs fine with my X5L.
I really like the patch. Just sounds great.
I attached a small fix for the “/apps/codecs/SOURCES”. Just runs this after the “mikmod_codec.patch” was applies.
I haven’t time to test it again, but it should work fine.

Resynced mikmod_codec to compile against recent svn (21930).
On my gigabeat S it works as expected.

Appears to be broken in r22187. Made clean with no other patches generated this when compiling for c200:

CC apps/codecs/mikmod.c
LD mikmod.codec
/home/michael/rockbox/build/apps/codecs/mikmod.o: In function `codec_main’:
mikmod.c:(.text+0x3bc): undefined reference to `add_pool’ mikmod.c:(.text+0x3c0): undefined reference to `drv_nos’ mikmod.c:(.text+0x3c4): undefined reference to `MikMod_RegisterDriver’ mikmod.c:(.text+0x3c8): undefined reference to `load_mod’ mikmod.c:(.text+0x3cc): undefined reference to `MikMod_RegisterLoader’ mikmod.c:(.text+0x3d0): undefined reference to `load_s3m’ mikmod.c:(.text+0x3d4): undefined reference to `load_xm’ mikmod.c:(.text+0x3d8): undefined reference to `load_it’ mikmod.c:(.text+0x3dc): undefined reference to `md_mixfreq’ mikmod.c:(.text+0x3e4): undefined reference to `MikMod_Init’ mikmod.c:(.text+0x3f8): undefined reference to `_mm_new_mem_reader’ mikmod.c:(.text+0×400): undefined reference to `Player_LoadGeneric’ mikmod.c:(.text+0×408): undefined reference to `dfree’ mikmod.c:(.text+0x40c): undefined reference to `Player_Start’ mikmod.c:(.text+0×418): undefined reference to `Player_SetPosition’ mikmod.c:(.text+0x41c): undefined reference to `VC_WriteBytes’ mikmod.c:(.text+0×428): undefined reference to `Player_Active’ mikmod.c:(.text+0x42c): undefined reference to `Player_Stop’ mikmod.c:(.text+0×430): undefined reference to `Player_Free’ mikmod.c:(.text+0×434): undefined reference to `MikMod_Exit’ collect2: ld returned 1 exit status
make: *** [/home/michael/rockbox/build/apps/codecs/mikmod.codec] Error 1

Builds under r22193. Added song length (during playback) and seek by time. Song length isn’t reliable as it doesn’t account for tempo changes.

Looks intresting.
I’ll check on this tonight

Built successfully and works well, but for some reason, none of my ITs will play. “Codec failure”, the error message shows.

Attached is a sample IT. It worked when I was using the plugin patch (I don’t anymore, having checked out a clean copy of the SVN).

I have looked into codec development a bit… both the interface and the platform dependant memory limitations a codec has. No platform has more than 1mb memory for the codec binary + its data it seems.(Hope i got this right) Based on this, i doubt this codec can successfully open any mod that is longer than…. lets say 500kb right now. Very often it already fails to open 300kb mods on platforms with 1mb codec memory(Sansa Fuze).

MikMod copies and converts all samples during the loading process potentially converting 8bit samples to 16bit, because that is the type the mixing routines can handle. Due to that its not easy to apply the trick the current modplayer in the SVN uses, abusing the filebuffer as read-only storage for the samples(and patterns? Didnt look too close but that could be done i guess), circumventing the memory limitation that way. The pattern data takes up quite a lot of space as well, compared to the samples its neglectable though.

This need to copy/convert samples on loading is what is breaking the neck of this codec right now in my opinion. At least the IT format supports compressed samples. There will be no way around unpacking these into a usable form and copying them into the codec space.

Modifying the mixing routines to be able to handle all common types of samples natively, only copying/converting compressed samples until we run out of memory and then using the filebuffer as read only storage for the sample data as much as we can like the SVN modplayer does sounds like the way to go. For low memory targets dumbing down mikmod to support individual formats to lower the memory consumption further might still be necessary. Each dumbed down version would be a codec on its own then. I wonder what the best way to go here is? Input on that will be welcome.

I will start working on the mixing changes, trying to get mikmod to use the filebuffer.

The annual update :).

Updated metatag parser to properly trim null characters from filenames. Misc small fixes. Also made a first real attempt to extend the codec api to provide scratch buffer allocation. Modify line 52 in mikmod.c to change the scratch buffer size. Right now it only works if you’re listening to mod files exclusively – switching codecs and playing other formats renders the audio buffer inaccessible and the bufalloc() fails.

Builds under 24213.

Glad to see that the task is still alive, but I’m going to continue to use the previous patch until it stops building or until that last issue is fixed (”Right now it only works if you’re listening to mod files exclusively”) - whichever comes first. :-)

Plugin. Builds under 27514. Updated Mikmod to the latest version in cvs (3.2.0b2+). Large reorganization of dependencies and code so it makes more sense, utilizes more of the plugin api, and compiles cleanly.

Replaced dbestfit mallocs with tlsf. Removed some unused/debug code.

Added entries for all mikmod-supported formats to viewers.config. Fixed some tabs. Removed more debug code and unused defines.

Still building under r27804, and works WONDERFULLY on the iPod Video (64MB of RAM). Kudos to you; maybe this could be commission-worthy soon? :)

Builds under r28037.

xqwyz commented on 2010-09-14 13:41

Works great on my X5L. Thanks for continuing work.
It may be useful to remove the mod codec though.

xqwyz commented on 2010-09-15 18:49

Powered off my X5L today while using MikMod today. My X5L hung up and I had reset it. Since then I get a #leak-file-handle error and can’t any modules.

This is an attempt to make mikmod_codec compatible with recent (28189) svn
Let me know if i the patch is incomplete.

The FW builds ok.
Building the simulator, I got these errors:

/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:5: error: ‘_C’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:6: error: ‘_S’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:9: error: ‘_B’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:9: error: ‘_P’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:11: error: ‘_N’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:13: error: ‘_U’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:13: error: ‘_X’ undeclared here (not in a function)
/home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/../../../firmware/libc/ctype.c:17: error: ‘_L’ undeclared here (not in a function)
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/../../../firmware/libc/ctype.o] Errore 1
* In attesa di lavori non terminati… In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/npertab.c:34:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/npertab.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/drv_nos.c:44:
/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
* [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/drv_nos.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mwav.c:44:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mwav.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mmalloc.c:34:
/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
* [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mmalloc.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/virtch.c:48:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/virtch.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/virtch_common.c:33:
/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
* [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/virtch_common.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/munitrk.c:34:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/sloader.c:39:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mdriver.c:50:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mdriver.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mmerror.c:42:
/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
* [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mmerror.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mplayer.c:44:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mplayer.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mlutil.c:39:
/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
* [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mlutil.o] Errore 1
make: * [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/munitrk.o] Errore 1
* [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/sloader.o] Errore 1
In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod.h:33,

               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mikmod_internals.h:47,
               from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/codecs/libmikmod/mloader.c:43:

/usr/include/stdio.h:339: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘→’ token
make: *** [/home/asettico-9.10/Sviluppo/rockbox/rockbox/build_sim/apps/codecs/libmikmod/mloader.o] Errore 1


@Rosso Maltese
I never tried building the simulator. I can’t tell if this is related to the actual code or the changes i made to the patch to make it build with recent changes.
I’m not much of a programmer, so I can’t directly answer your question ;)

Posting here because there seem to be people with knowledge about .mod around here.

We currently don’t check if the files we are trying to play is a valid file (among other nasty stuff in the .mod metadata parser). And the proposed patch doesn’t seem to fix it.

I.e.: We’re attempting to play and add to tagcache .mod which are plain text files (some files created during kernel compilation end with .mod). I think that’s bad. The attached patch seems to fix it for the text files, but I don’t know if it makes things worse for real .mod files. Any comment?

Better (with correct logic) patch.

From my old modplayer (only *.mod files) from the time of the PC demo scene - you can choose the 4 channel signatures only:

SignTab db ‘M.K.’,’M!K!’,’FLT4’,’FLT8’,’OCTA’,’2CHN’,’4CHN’,’6CHN’,’8CHN’

               db '10CH','12CH','14CH','16CH','18CH','20CH','22CH','24CH','26CH'
               db '28CH','30CH','32CH','CD81'

M.K, M!K! → NoiceTracker / Protracker 4 channel module
FLT4, FLT8 → Startrekker 4/8 channel module
OCTA → OctaComposer 8 channel module
2CHN to 32CHN → FastTracker from 2 to 32 channel module
CD81 - Falcon 8 channel module ?

Yea, that’s about what mikimod also detects. But it’s not clear to me what you are suggesting.

You said “We currently don’t check if the files we are trying to play is a valid file”, so i thought it’s about detecting a mod file and i’ve given the other types of the signature here too, so you could possibly add some of them. I didn’t look deeply at the patch. Now i suppose it’s not about detection if you write that it detects it…

No you are right, I was too tired to understand you properly :)

I guess I can copy from mikimod, I’ve had a quick look.


Available keyboard shortcuts


Task Details

Task Editing