fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] Making MIDI player read from a buffer


From: Matt Giuca
Subject: Re: [fluid-dev] Making MIDI player read from a buffer
Date: Sat, 4 Dec 2010 13:55:51 +1100

Hi guys,

I have completed an initial cut at the implementation of the new
fluid_player_add_mem API call, which lets you add a MIDI file to the
playlist from a buffer in memory, rather than a filename. This
required extensive re-architecting of the internal mechanism for
loading files. The old fluid_player_add no longer reads a file in a
few bytes at a time -- it allocates a buffer for the whole file, reads
it in, then uses the new memory based loader.

I currently have it in a Bazaar branch in Launchpad here:
https://code.launchpad.net/~mgiuca/fluidsynth/midi-buffer
use:
bzr branch lp:~mgiuca/fluidsynth/midi-buffer

The full patch against the trunk (SVN r393) is viewable and downloadable here:
http://bazaar.launchpad.net/~mgiuca/fluidsynth/midi-buffer/revision/356?compare_revid=336.1.3

Note that I have added a new section with a full example to the documentation:
http://bazaar.launchpad.net/~mgiuca/fluidsynth/midi-buffer/revision/352
If anyone is interested, try running this example and see if there are
any problems.

It isn't ready to merge yet, as there is still a bit of a discussion
to be had about garbage collection. To recap, we had five proposals
for how the user code and our code will allocate and free the buffer:

1. Stealing from client-malloc; fluid will call free(). Won't work
with different allocators other than malloc.
2. Stealing from client-fluid_alloc; fluid will call fluid_free(). At
least it lets fluid control the allocator.
3. Borrowing; fluid will not free memory. Requires complicated memory
management in the client.
4. Borrowing, with a "destructor" callback. Lets the client control
allocation and freeing, and can easily simulate #1 or #2.
5. Copying. Client must free, but can do it right away. Easiest
method, but inefficient.

I was leaning towards #2 (client allocs, fluid frees). But having
written that example, it's pretty annoying. I'm now leaning toward's
David's suggestion, #5, in which fluid_player_add_mem simply copies
the buffer immediately, and the client is able to free it immediately.
Note that in my example, I was forced to malloc and copy the buffer;
this copying approach would let me simply send a pointer to the global
buffer in to FluidSynth.

Matt Giuca



reply via email to

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