[Top][All Lists]

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

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

From: David Henningsson
Subject: Re: [fluid-dev] Voice-stealing logic, and more
Date: Sun, 04 Jul 2010 11:04:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100423 Thunderbird/3.0.4

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

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

// David

reply via email to

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