GNOME Bugzilla – Bug 403992
[new plugin] timidity based midi decoder
Last modified: 2007-07-19 09:08:16 UTC
I wrote a small plugin to decode audio/midi to audio/x-raw-int based on timidity. The source can be found on http://www.blue-gate.be/sources/gst-timidity-0.10.0.1.tar.gz You also libtimidity (http://libtimidity.sourceforge.net) installed to compile this plugin, together with a working timidity configuration. Some comments on how to implement caps negotiation would be welcome because currently the output format is fixed while timidity supports different output formats.
Created attachment 81824 [details] timidity plugin code For archiving reasons, this is the standalone plugin tarball.
http://www.blue-gate.be/sources/gst-timidity-0.10.0.2.tar.gz has a second element which implements midi decoding based on http://wildmidi.sourceforge.net. The quality of this midi library seems better than the original libtimidity. (timidity has problems with the soundfont from http://www.titanicsf.com/)
Created attachment 82045 [details] [review] Patch against gst-plugins-bad to add the timidity plugin
hi, I tried the plugin. Somehow the patch seems to be broken. it tried to patch all files in to gst-plugins-bad root dir. There are some issues still. First the mid_init(NULL) failed as it could not find the config. Under my ubuntu, the config is "/etc/timitidy/timidity.cfg". We should check the usual locations per configure. During playback I get: (gst-launch-0.10:21602): GStreamer-CRITICAL **: gst_tag_list_free: assertion `GST_IS_TAG_LIST (list)' failed. Will try to fix that one, but then I belive it could go to -bad. Would it make sense to merge the wildmidi one, so that there is only one plugin, but several elements (or even just a enum to choose the engine)?
is the config one passes to mid_init() determining which soundfont gets used? If so should it be a property then and you open the lib when going from READY_TO_PAUSED?
The config passed to mid_init() is indeed the one that determines the soundfont. Putting that in a property is tricky imho because mid_init() is application wide. e.g. you can not have 2 instances of the plugin with 2 different configurations in the same application. That's why I chose to not load the plugin if a sane configuration could not be found.
valgrind is still not too happy about t, but seems to work now ==26244== Conditional jump or move depends on uninitialised value(s) ==26244== at 0x46BC0A2: s32tos16 (output.c:69) ==26244== by 0x46BD02D: compute_data (playmidi.c:628) ==26244== by 0x46BD4A8: mid_song_read_wave (playmidi.c:780) ==26244== by 0x46B3B7C: gst_timidity_loop (gsttimidity.c:500) ==26244== by 0x4095D95: gst_task_func (gsttask.c:192) ==26244== by 0x4165CE7: g_thread_pool_thread_proxy (gthreadpool.c:265) ==26244== by 0x416438E: g_thread_create_proxy (gthread.c:553) ==26244== by 0x41B20FA: start_thread (pthread_create.c:261) ==26244== by 0x427C8ED: clone (in /usr/lib/debug/libc-2.4.so) ==26244== ==26244== Conditional jump or move depends on uninitialised value(s) ==26244== at 0x46BC0AE: s32tos16 (output.c:72) ==26244== by 0x46BD02D: compute_data (playmidi.c:628) ==26244== by 0x46BD4A8: mid_song_read_wave (playmidi.c:780) ==26244== by 0x46B3B7C: gst_timidity_loop (gsttimidity.c:500) ==26244== by 0x4095D95: gst_task_func (gsttask.c:192) ==26244== by 0x4165CE7: g_thread_pool_thread_proxy (gthreadpool.c:265) ==26244== by 0x416438E: g_thread_create_proxy (gthread.c:553) ==26244== by 0x41B20FA: start_thread (pthread_create.c:261) ==26244== by 0x427C8ED: clone (in /usr/lib/debug/libc-2.4.so)
I have added the wildmidi one to cvs as well. I had to do some fixes here to. Unfortunately the wildmidi lib is leaky and has some bugs: http://sourceforge.net/tracker/index.php?func=detail&aid=1657370&group_id=42635&atid=433744 http://sourceforge.net/tracker/index.php?func=detail&aid=1657358&group_id=42635&atid=433744 Wouter, could you please make a documentation header patch and if possible come up with a simple testcase. This is needed to get those sooner or later into plugins-good.
*** Bug 159705 has been marked as a duplicate of this bug. ***
Seeing that this seems to have been committed, can we close this bug now? (Maybe create a clone bug for the missing docs/unit test if you want to have an open bug for those ...)
Tim, I'll try to do the doc header and simple tests during the next days. Then I close the bug.
Cool (sorry, just going through the list of open bugs trying to weed some out).
Both elements now have docs.
Added a test now. 2007-07-19 Stefan Kost <ensonic@users.sf.net> * tests/check/Makefile.am: * tests/check/elements/timidity.c (GST_START_TEST, timidity_suite, main): Add typefind test for midi. Both timidity and wildmidi have bugs and are under-maintained. Would it still make sense to try to move this to good, for the sake of getting it installed by default more widely?