fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] fluidsynth plugin for the Music Player Daemon


From: Bernat Arlandis i Mañó
Subject: Re: [fluid-dev] fluidsynth plugin for the Music Player Daemon
Date: Sat, 21 Feb 2009 10:50:14 +0100
User-agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)

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ñó




reply via email to

[Prev in Thread] Current Thread [Next in Thread]