Max Kellermann escrigué: > Hi, > > I am the lead developer of the Music Player Daemon project, and I have > written a fluidsynth plugin for it: > > > http://git.musicpd.org/cgit/master/mpd.git/tree/src/decoder/fluidsynth_plugin.c > > There were lots of difficulties during the development, and I couldn't > solve some of them. Let me drop a load of rants: > > - the API expects "char*" parameters, but I have only "const char*" - > that means I have to duplicate all strings which are passed to > fluidsynth. > > - fluidsynth is undocumented. > > http://www.nongnu.org/fluid/api/ lists just the prototypes > > http://www.toncat.de/fluidsynth/ and > http://personales.ya.com/berarma/fluidsynth/html/ are a good start, > but so incomplete that they're mostly unusable. > > Most of the time, I had to read fluidsynth's source, or the source > of applications using fluidsynth. For my purposes, there is no good > sample code. > > - there is no way to tell whether the "player" has finished playing a > MIDI file - the "status" attribute is not exposed. Even the > "fluidsynth" program does not exit when the song is finished, > because it doesn't know either. > > - the "player" insists on playing in real-time, all my attempts to > fill MPD's internal audio buffer as fast as possible failed, there > was only silence in the buffer after the fluid_synth_write_s16() > call. The same might be true when MPD is paused - I suspect > fluidsynth will continue playback, but havn't tried yet (wasted more > than enough time with figuring out the API). I don't want > fluidsynth to make any assumptions on the wall clock - I want to > read PCM samples out of it whenever I feel like doing so, as fast as > the CPU can handle it. Just like all the other decoder libraries. > > - error handling in fluidsynth is awful. Most functions return an > undocumented "int", its meaning can only be derived from reading the > source, but I cannot grasp what's gone wrong, I cannot generate a > usable error message. Non-fatal errors (as well as fatal errors) > are printed to the log file, but the logging subsystem of fluidsynth > is not thread safe (i.e. thread aware), so I cannot use the logging > callback as a hack. > > In general, libraries shouldn't log at all, they should return > good error codes/messages in some way. The application should > decide what to do when an error occurs. > > - I don't want fluidsynth to create a new thread. Synthesize the MIDI > file synchronously in the thread which called the library. > > Please keep me on Cc in responses, because I'm not subscribed to the > mailing list. > > Max > Hi Max.
Your suggestions are really good. I'm already trying to help with some of these, some others are planned for a new development branch, but it's going to take some time. Development has been stagnant for a long time and we're a few developers with very limited time. I hope to get started any time soon on new development, although I can't tell you for sure when this will happen, and I'm looking forward to address all these issues. I'll try to keep you informed since it's very important having feedback from other developers using FS. Thank you. Best regards. -- Bernat Arlandis i Mañó ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
