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

[Elimar Green]

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.

> * Refactor voice class into voice and rvoice, whereas rvoice stands for
> the hard real-time, dynamic part of the voice and the voice stands for
> generators, modulators, midi interpretation. [DONE]
>
> * Make event queue for thread boundary, so the voice can send updates to
> the rvoice [DONE]
>
> * Refactor mixer class out of fluid_synth for buffers, reverb and
> chorus, i e most of fluid_synth_one_block [IN PROGRESS]
>
> * 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.

>
> 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?

> In addition, I think we could:
>
> * 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.
>
> * 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.

>
> 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.

> 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.

>
> // David
>

Cheers!

Elimar