Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by Jason Yu (captainkewl) - Wednesday, 26 March 2008, 06:22 GMT
Last edited by Frank Gevaerts (fg) - Sunday, 12 December 2010, 15:05 GMT
Task Type Patches
Category Plugins
Status Closed
Assigned To No-one
Operating System iPod 5G
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Player for various tracker module formats supported by MikMod 3.1.12 -- http://sourceforge.net/projects/mikmod/

* 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 snowf.it
* Had to butcher libmikmod a good bit to get it to compile. As has been noted elsewhere (http://forums.rockbox.org/index.php?topic=4716.msg38535#msg38535), there are colliding namespaces (BOOL, nop) and undefined types (FILE).
* Based on midiplay by Karl Kurbjun
* dbestfit malloc() replacement by Daniel Stenberg
This task depends upon

Closed by  Frank Gevaerts (fg)
Sunday, 12 December 2010, 15:05 GMT
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.
Comment by Marc Guay (Marc_Guay) - Wednesday, 26 March 2008, 23:59 GMT
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.
Comment by Thom Johansen (preglow) - Thursday, 27 March 2008, 18:51 GMT
On Coldfire targets, GCC seems to puke on load_mod.c. Don't we love buggy compilers?
Comment by Jason Yu (captainkewl) - Friday, 28 March 2008, 04:38 GMT
Seems to build okay after dropping the -O flags. Sorry -- next patch I'll actually test building on other targets.
Comment by Thom Johansen (preglow) - Friday, 28 March 2008, 20:27 GMT
Try simulator builds too, while you're at it. There seems to be some system header mismatch here that makes it not work.
Comment by Jason Yu (captainkewl) - Tuesday, 01 April 2008, 18:41 GMT
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.
Comment by Thom Johansen (preglow) - Tuesday, 01 April 2008, 18:45 GMT
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.
Comment by Jason Yu (captainkewl) - Friday, 04 April 2008, 05:29 GMT
* 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.
Comment by Craig Mann (inigomontoya) - Sunday, 18 May 2008, 08:59 GMT
Now compiles under r17564
Comment by William Peters (w1ll14m) - Wednesday, 21 May 2008, 22:46 GMT
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?
Comment by Craig Mann (inigomontoya) - Thursday, 22 May 2008, 03:21 GMT
Sorry about that, my bad. This should fix the messages when patching.
Comment by Craig Mann (inigomontoya) - Thursday, 22 May 2008, 03:22 GMT
forgot to attach it
Comment by William Peters (w1ll14m) - Thursday, 22 May 2008, 21:13 GMT
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.
Comment by Jason Yu (captainkewl) - Tuesday, 24 June 2008, 21:32 GMT
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.
Comment by Jason Yu (captainkewl) - Thursday, 31 July 2008, 05:51 GMT
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.
Comment by Jason Yu (captainkewl) - Saturday, 16 August 2008, 21:07 GMT
Compiles under 18298.
Comment by Michael Carr (Strife89) - Monday, 08 September 2008, 23:32 GMT
And it works beautifully! :)
Comment by Panagiotis Papadopoulos (pano) - Monday, 15 September 2008, 11:54 GMT
Is it possible to integrate this patch to show the files in the WPS?
Comment by Panagiotis Papadopoulos (pano) - Monday, 15 September 2008, 21:02 GMT
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
Comment by Marc Guay (Marc_Guay) - Wednesday, 17 September 2008, 01:35 GMT
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.
Comment by Ben L (ben8383) - Thursday, 30 October 2008, 18:10 GMT
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.
Comment by Robert Menes (RMenes379) - Monday, 03 November 2008, 18:42 GMT
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.
Comment by Jason Yu (captainkewl) - Tuesday, 04 November 2008, 04:24 GMT
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.
Comment by Dave Chapman (linuxstb) - Tuesday, 04 November 2008, 17:12 GMT
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.
Comment by Jason Yu (captainkewl) - Friday, 21 November 2008, 22:46 GMT
Compiles under r19176.
Comment by Jason Yu (captainkewl) - Tuesday, 09 December 2008, 16:52 GMT
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.
Comment by Robert Menes (RMenes379) - Wednesday, 17 December 2008, 18:43 GMT
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.
Comment by William Peters (w1ll14m) - Sunday, 28 December 2008, 18:03 GMT
Nice! works good on my Gigabeat S too.
Also i have some tiny issues when refilling the buffer.
Comment by Pierce Staab (Pjstaab) - Monday, 29 December 2008, 07:17 GMT
Plays fine, how about tags?
Comment by Robert Menes (RMenes379) - Monday, 29 December 2008, 16:37 GMT
Plays very nicely on my iPod video as well.
Comment by Jason Yu (captainkewl) - Sunday, 11 January 2009, 06:12 GMT
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.
Comment by Michael Carr (Strife89) - Tuesday, 13 January 2009, 12:53 GMT
"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?
Comment by Pierce Staab (Pjstaab) - Wednesday, 14 January 2009, 04:31 GMT
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.
Comment by Jason Yu (captainkewl) - Sunday, 18 January 2009, 19:45 GMT
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.
Comment by Pierce Staab (Pjstaab) - Wednesday, 21 January 2009, 01:57 GMT
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.
Comment by Pierce Staab (Pjstaab) - Wednesday, 21 January 2009, 02:11 GMT
Well I tried it again and it worked.
Comment by Pierce Staab (Pjstaab) - Wednesday, 21 January 2009, 02:18 GMT
Maybe not.
Comment by Pierce Staab (Pjstaab) - Wednesday, 21 January 2009, 02:36 GMT
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.
Comment by Michael Carr (Strife89) - Monday, 26 January 2009, 12:57 GMT
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. :)
Comment by Pierce Staab (Pjstaab) - Wednesday, 28 January 2009, 23:09 GMT
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.
Comment by Pierce Staab (Pjstaab) - Monday, 02 February 2009, 03:30 GMT
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.
Comment by Tony Huynh (insanepotato) - Sunday, 08 February 2009, 02:34 GMT
Works like a charm =]
Comment by William Peters (w1ll14m) - Thursday, 12 February 2009, 22:36 GMT
Quick-Fix mikmod CODEC patch to compile again with recent SVN.
Comment by jason (jasonmog) - Friday, 27 February 2009, 04:22 GMT
cool so where's the file that i just copy into my rockbox installation and it works? thx
Comment by Joshua Simmons (mud) - Friday, 27 February 2009, 04:54 GMT
@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: http://www.rockbox.org/twiki/bin/view/Main/DocsIndex#For_Developers .
Comment by Michael Carr (Strife89) - Saturday, 11 April 2009, 01:24 GMT
I hope this patch hasn't died. The plugin, at least, seems to work astoundingly well. Surely it could be committed?
Comment by Boris Gjenero (dreamlayers) - Saturday, 11 April 2009, 03:10 GMT
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.
Comment by Robert Menes (RMenes379) - Saturday, 11 April 2009, 03:31 GMT
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.
Comment by Boris Gjenero (dreamlayers) - Saturday, 11 April 2009, 17:03 GMT
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.
Comment by Jason Yu (captainkewl) - Sunday, 12 April 2009, 01:43 GMT
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.
Comment by David Brown (ep0ch) - Wednesday, 15 April 2009, 16:05 GMT
cutting out everything but MOD support kinda defeats the purpose of this patch...
Comment by Michael Carr (Strife89) - Wednesday, 15 April 2009, 19:39 GMT
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?
Comment by Michael Carr (Strife89) - Wednesday, 15 April 2009, 20:00 GMT
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.
Comment by XqWyZ (xqwyz) - Thursday, 07 May 2009, 15:10 GMT
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.
Comment by William Peters (w1ll14m) - Friday, 17 July 2009, 22:06 GMT
Resynced mikmod_codec to compile against recent svn (21930).
On my gigabeat S it works as expected.
Comment by Michael Carr (Strife89) - Thursday, 06 August 2009, 17:55 GMT
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+0x400): undefined reference to `Player_LoadGeneric'
mikmod.c:(.text+0x408): undefined reference to `dfree'
mikmod.c:(.text+0x40c): undefined reference to `Player_Start'
mikmod.c:(.text+0x418): undefined reference to `Player_SetPosition'
mikmod.c:(.text+0x41c): undefined reference to `VC_WriteBytes'
mikmod.c:(.text+0x428): undefined reference to `Player_Active'
mikmod.c:(.text+0x42c): undefined reference to `Player_Stop'
mikmod.c:(.text+0x430): undefined reference to `Player_Free'
mikmod.c:(.text+0x434): undefined reference to `MikMod_Exit'
collect2: ld returned 1 exit status
make: *** [/home/michael/rockbox/build/apps/codecs/mikmod.codec] Error 1
Comment by Jason Yu (captainkewl) - Friday, 07 August 2009, 05:21 GMT
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.
Comment by William Peters (w1ll14m) - Friday, 07 August 2009, 14:07 GMT
Looks intresting.
I'll check on this tonight
Comment by Michael Carr (Strife89) - Friday, 07 August 2009, 16:17 GMT
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).
Comment by Michael König (mkoenig) - Friday, 09 October 2009, 12:16 GMT
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.
Comment by Jason Yu (captainkewl) - Monday, 11 January 2010, 05:20 GMT
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.
Comment by Michael Carr (Strife89) - Tuesday, 26 January 2010, 00:04 GMT
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. :-)
Comment by Jason Yu (captainkewl) - Wednesday, 21 July 2010, 21:38 GMT
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.
Comment by Jason Yu (captainkewl) - Friday, 23 July 2010, 01:15 GMT
Replaced dbestfit mallocs with tlsf. Removed some unused/debug code.
Comment by Jason Yu (captainkewl) - Sunday, 08 August 2010, 04:04 GMT
Added entries for all mikmod-supported formats to viewers.config. Fixed some tabs. Removed more debug code and unused defines.
Comment by Michael Carr (Strife89) - Saturday, 14 August 2010, 05:08 GMT
Still building under r27804, and works WONDERFULLY on the iPod Video (64MB of RAM). Kudos to you; maybe this could be commission-worthy soon? :)
Comment by Jason Yu (captainkewl) - Wednesday, 08 September 2010, 04:17 GMT
Builds under r28037.
Comment by XqWyZ (xqwyz) - Tuesday, 14 September 2010, 13:41 GMT
Works great on my X5L. Thanks for continuing work.
It may be useful to remove the mod codec though.
Comment by XqWyZ (xqwyz) - Wednesday, 15 September 2010, 18:49 GMT
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.
Comment by William Peters (w1ll14m) - Friday, 01 October 2010, 17:26 GMT
This is an attempt to make mikmod_codec compatible with recent (28189) svn
Let me know if i the patch is incomplete.
Comment by Rosso Maltese (asettico) - Tuesday, 05 October 2010, 15:20 GMT
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
make: *** 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
make: *** [/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
make: *** [/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
make: *** [/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
make: *** [/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
make: *** [/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
make: *** [/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

HTH
Comment by William Peters (w1ll14m) - Tuesday, 05 October 2010, 19:56 GMT
@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 ;)
Comment by Thomas Martitz (kugel.) - Thursday, 25 November 2010, 17:24 GMT
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?
Comment by Thomas Martitz (kugel.) - Thursday, 25 November 2010, 17:56 GMT
Better (with correct logic) patch.
Comment by Szymon Dziok (b0hoon) - Thursday, 25 November 2010, 18:48 GMT
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 ?
Comment by Thomas Martitz (kugel.) - Thursday, 25 November 2010, 23:53 GMT
Yea, that's about what mikimod also detects. But it's not clear to me what you are suggesting.
Comment by Szymon Dziok (b0hoon) - Friday, 26 November 2010, 11:56 GMT
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...
Comment by Thomas Martitz (kugel.) - Friday, 26 November 2010, 17:59 GMT
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.

Loading...