Hi, 

 

>Maybe it would also be worthwhile to look at the chrous and reverb code. At 
>least on my machine and with the setup I use, the effects take up a large 
>proportion of processing time. And that processing is always single threaded...

 

Effects processing (reverb, chorus) are executed after the processing of all 
voices rendering (which is single /multi-thread). Effects is only single 
threaded, because they are common to all voices.

For information internal code in the actual reverb (freeverb: 
//ccrma.stanford.edu/~jos/pasp/Freeverb.html)  is the processing of:  8 combs 
filters + 8 first order low pass filters + 4 all-pass filters + stereo unit. 
When executed on a cpu with math coprocessor the whole reverb load is 
equivalent to: 4,1 x 1 voice load.

Chorus is:  N time variant delays lines (modulated by LFO). It is special as 
the cpu load depends of the number of delay lines chosen.

 

>At least on my machine and with the setup I use, the effects take up a large 
>proportion of processing time.

Please at the occasion, if the hardware you use is dedicated to a stand alone 
synthesizer, could you run the profile commands and return the results (with 
CPU model) ?.

 

# for reverb / chorus performance measurement

>prof_set_notes 100  # must be set so that you get "total(%)" result never 
>above 100%

>chorus on

>reverb on

>prof_start 5 1000

 

cheers.

jjc

 

 

 

> Message du 16/04/18 10:34
> De : "Marcus Weseloh" 
> A : "FluidSynth mailing list" 
> Copie à : 
> Objet : Re: [fluid-dev] Parallelize rendering using openMP
> 
>
Hi Tom,
> 
> 2018-04-14 17:58 GMT+02:00 Tom M. :
> > Using FluidR3_GM.sf2 the cpu load looks better, but I'm yet quite far from 
> > the "perfect" scalability that your profiling interface gives you JJC.
> 
> Well, assuming you are using "normal" MIDI files as input and test with that, 
> the advantages of parallel rending are bound to be much smaller than with an 
> artificial test that tests extreme cases, I think.
>  
> > Still I think it's worth evaluating what job openMP and other refactorings 
> > can do here. David Henningsson once told me that the parallel renderer was 
> > more like a (failed) experiment. So please see this current work as my 
> > little experiment.
> 
> Please don't get me wrong, I also think that it's worth evaluating a better 
> parallel rendering implementation. So I am all for your approach of just 
> testing it out. I was just curious if you had done more measurements on 
> synchronization overhead.
>  
> > Additionally I want to revise the current implementation, like using a 
> > parallel logarithmic buffer reduction to mix audio between threads or 
> > rethinking data layout and memory accesses in general, hoping this makes it 
> > more efficient.
> 
>
That sounds good. Maybe it would also be worthwhile to look at the chrous and 
reverb code. At least on my machine and with the setup I use, the effects take 
up a large proportion of processing time. And that processing is always single 
threaded...
> 
> Cheers,
> 
>     Marcus
>




_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev

Reply via email to