Re: [fluid-dev] Voice-stealing logic, and more

[David Henningsson]

On 2010-07-04 05:21, Elimar Green wrote:
> Hello David,
> 
> Definitely more progress than I expected.. Sweet!
> 
> On Wed, Jun 30, 2010 at 3:53 AM, David Henningsson
> <address@hidden> wrote:
> 
>>
>> Yeah. To give you (and myself!) a rough overview, here are some work items:
>>
>> * Refactor envelopes, lfos and resonant filter into separate classes [DONE]
>>
>> * Move source files into new directory structure [Done, except for
>> Makefile.am]
> Not sure exactly what you mean about the Makefile.am.  I see you have
> the src/Makefile.am just referencing the source files in the sub
> directories.  Seems like that should work.

Exactly, just need to update it with my latest subdir changes.

>> * Make fluid_synth support different thread scenarios: single-thread,
>> mutex-protected, both scenarios with and without rendering in parallel.
>> Should we keep the existing queue mechanism? [TODO]
> 
> Which queue mechanism?  Do you mean the lock-free queue primitive that
> I created, the use of it by multiple non-synth threads or the return
> queue?  It seems like the queue per non-synth thread is no longer
> needed when a mutex is used for all state machine operations.  The
> return queue may be necessary for deferring some operations to
> non-synth context.

I think we could remove both of them. Currently the return queue only
processes FLUID_EVENT_QUEUE_ELEM_FREE_PRESET, which it does by locking
the synth mutex anyway.

>> That should be it for having a stable synth core without reordering
>> problems. IMO, enough for a release.
> Sounds great to me.  Version 1.2?

Hmm, I'll go with 1.1.2, the changes don't bring in any cool new
features, from the user end point this is more of a bug fix release.

>> * Make fast-render super-fast by reworking core thread implementation
>> and the fluid midi player callback. The new mixer class is prepared for
>> rendering more than one block at a time, thus reducing the amount of
>> synchronization.

I've committed code for that now, but I was hoping for a little more...
 it wasn't as super-fast as expected. For my test piece, here are the
benchmarks:

Fluidsynth trunk:
-z 64, cores=1 - 13.6 s
-z 64, cores=3 - 16.0 s
-z 8192, cores=1 - 12.2 s
-z 8192, cores=3 - 10.6 s

Fluidsynth 1.1.1 (for reference):
-z 64, cores=1 - 13.6 s
-z 64, cores=3 - 17.4 s
-z 8192, cores=1 - 13.1 s
-z 8192, cores=3 - 16.4 s

I think it is so much synchronization overhead taking place that we
don't see more of an improvement.

>> * Libfluidsynth has lots of dependencies, so split libfluidsynth into
>> two libraries, where the new "libfluidsynthcore" library should be
>> enough for more embedded use cases, such as dssi. It should only depend
>> should on libc, and optionally glib for thread support (e g, without
>> thread support for iPhone).
> 
> Both of those sound good.  We could even go as far as making each
> driver its own dynamically loaded plugin.  There is code in Swami
> which does this using glib, which may be useful as a reference.

Seen from a packagers perspective, are you expecting the packager to
output one package for each driver then?

>> Right. The question is whether we can make the decision with "static"
>> data only, i e no data from the rvoice. Today the voice-stealing
>> algorithm looks for static data only, except for one piece of
>> information coming from the volume envelope. Can we live without that or
>> replace it with something else, that would be great.
> 
> Yes, I think the synth process could do a volume calculation for each
> voice, perhaps taking into account whether the volume may increase
> (currently attack stage, etc).  This value could be atomically
> written/read and used in the voice stealing logic.  Thats just a quick
> thought on it though, might be overlooking something.

That's a solution, I just don't like having to spend CPU time updating
things that are so seldom used.

I have been thinking about a compromise which would mean duplicating the
volume envelope (i e the voice and the rvoice has one copy each) and
then the renderer overhead would be to just atomically update
synth->ticks. What do you think about that?

>> Thanks! Well, I'll just finish the mixer (hopefully today or tomorrow),
>> then I think the first thing you should do is to get accustomed to the
>> new code and structure. See if you understand everything, if you need to
>> slap my face for not following code conventions (I keep forgetting about
>> them) ;-) , and if there seem to be any problems with the new stuff.
>> Think. Just so we get everything really right this time!
> 
> Checking it out..  I'll look it over in the next few days.  The work
> you are doing sounds great though and I really doubt there will be
> anything that I'll have a problem with.

Heh, thanks for your confidence :-)

Getting all use cases right requires some thought, and it is easy to
forget a case that is unimportant to me but very important to someone
else...

// David