[Top][All Lists]

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

Re: [fluid-dev] Fluidsynth questions: 2.0.5 release / threading

From: Tim Janik
Subject: Re: [fluid-dev] Fluidsynth questions: 2.0.5 release / threading
Date: Fri, 19 Apr 2019 12:23:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hi Tom.

On 19.04.19 09:27, Tom M. wrote:
>> Another question I have is related to threading. I'd like to use two 
>> fluid_synth_t* instances in two different threads with two different 
>> soundfonts to render two different midi tracks. I'm assuming that I can call 
>> fluid_synth_process() independently on these two instances from two threads 
>> and they will not interfere in any way, right?
> Yes. Each synth has it's own mutex, which is used if the setting 
> "synth.threadsafe-api" is true (the default). Apart from that all synths 
> share a sample cache as global ressource, which is always mutex protected.
>> And if I do so, the processing speed would effectively be doubled if I have 
>> 2 cores, because the rendering would be fully parallel?
> It should, I haven't tested it. However I cannot recommend to create multiple 
> synths just to increase rendering speed.

The reason we're considering that is, in Beast there's a (potentially) huge
amount of synthesis modules processing audio data in parallel. At runtime, we
are devising a dependency related processing plan and share the rendering load
across all available cores already. So adding audio rendering threads outside
our plan is likely to impact performance badly. The most efficient way to
process these synthesis networks is if we can integrate multiple fluidsynth
instances the same way we treat other modules by just calling a process()
function, process them in parallel, and avoid individual module implementations
spawning additional own threads.

> Tom

Yours sincerely,
Tim Janik

Free software author.

reply via email to

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