Re: Fluidsynth questions: 2.0.5 release / threading

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Fluidsynth questions: 2.0.5 release / threading

Tom M.
Hi Stefan,

pls. also send a copy to our mailing list the next time.

> I've seen that my fixes should be in 2.0.5. Do you have an approximate idea when this fluidsynth release will be available?

Today.

> 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. You should instead create only one synth. Before creation, set the setting "synth.cpu-cores" to the number of cores you want to use for rendering [1]. Load all soundfonts you want to use into the synth. Make sure every MIDI track you want to render is playing on its own MIDI channel. Then you can use fluid_synth_sfont_select() to select the soundfont for each MIDI channel [2]. And by using multichannel rendering, you will also be able to render each MIDI channel to its own audio channel, if required, see [3].


[1] http://www.fluidsynth.org/api/fluidsettings.xml#synth.cpu-cores
[2] http://www.fluidsynth.org/api/synth_8h.html#af66d59e942a14ee9f2d28444885bd27b
[3] http://www.fluidsynth.org/api/fluidsynth_process_8c-example.html


Tom



_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluidsynth questions: 2.0.5 release / threading

Stefan Westerfeld
   Hi!

On Fri, Apr 19, 2019 at 09:27:35AM +0200, 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.

All right, I didn't even know that there is a sample cache so far. Suppose I
load the same huge soundfont into two different fluid_synth_t objects. Will
that double my memory usage?

And how is the situation if that soundfont was loaded from memory?

   Cu... Stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluidsynth questions: 2.0.5 release / threading

Tom M.
> All right, I didn't even know that there is a sample cache so far. Suppose I
> load the same huge soundfont into two different fluid_synth_t objects. Will
> that double my memory usage?

No. Only the structural information of a soundfont is allocated for every synth, e.g. preset zones, instrument zones, their ranges, generators and modulators. But the huge rest of the soundfont, i.e. the sample data, are globally reference counted and allocated only once.

> And how is the situation if that soundfont was loaded from memory?

fluidsynth will treat soundfonts in memory just like usual files, there is no special treatment. I.e. fluidsynth will not use the samples already located in memory because fluidsynth takes ownership of every soundfont it loads. That means, fluidsynth will load the samples into the global sample cache just if it came from a file. Once loaded it closes the file or memory region.


Tom




_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluidsynth questions: 2.0.5 release / threading

Tim Janik
In reply to this post by Tom M.
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

https://testbit.eu/timj
Free software author.

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluidsynth questions: 2.0.5 release / threading

Ceresa Jean-Jacques
In reply to this post by Tom M.

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

 

As explained by Tom, you don't need to create two fluid_synth_t* instances in two different thread to just to increase rendering speed. Creating  synth(s) in one thread is sufficient.

And the only reason one could need to create 2 synths would be to render more than 16 MIDI channels (i.g 16 MIDI channels per synth).

 

If one need multiple synths, remember that each synth's instance must have its own audio driver instance. This case is complicated when different audio driver instance are using the same device (audio adapter). It should works only if the OS audio driver accepts this. Of course Alsa or Dsound will accept this, but the cpu load will be augmented.

jjc.

> Message du 19/04/19 09:34

> De : "Tom M." <[hidden email]>
> A : "Stefan Westerfeld" <[hidden email]>
> Copie à : [hidden email], "Tim Janik" <[hidden email]>
> Objet : Re: [fluid-dev] Fluidsynth questions: 2.0.5 release / threading
>
> Hi Stefan,
>
> pls. also send a copy to our mailing list the next time.
>
> > I've seen that my fixes should be in 2.0.5. Do you have an approximate idea when this fluidsynth release will be available?
>
> Today.
>
> > 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. You should instead create only one synth. Before creation, set the setting "synth.cpu-cores" to the number of cores you want to use for rendering [1]. Load all soundfonts you want to use into the synth. Make sure every MIDI track you want to render is playing on its own MIDI channel. Then you can use fluid_synth_sfont_select() to select the soundfont for each MIDI channel [2]. And by using multichannel rendering, you will also be able to render each MIDI channel to its own audio channel, if required, see [3].
>
>
> [1] http://www.fluidsynth.org/api/fluidsettings.xml#synth.cpu-cores
> [2] http://www.fluidsynth.org/api/synth_8h.html#af66d59e942a14ee9f2d28444885bd27b
> [3] http://www.fluidsynth.org/api/fluidsynth_process_8c-example.html
>
>
> Tom
>
>
>
> _______________________________________________
> fluid-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fluidsynth questions: 2.0.5 release / threading

Tom M.
The use-case for multiple synth instances as outlined by Tim sounds plausible
to me.

> And the only reason one could need to create 2 synths would be to render
more than 16 MIDI channels (i.g 16 MIDI channels per synth).

Let me just add that the synth itself is capable to render up to 256 MIDI
channels, see the setting "synth.midi-channels":
http://www.fluidsynth.org/api/fluidsettings.xml#synth.midi-channels

Tom




_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev