fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] parallel loading of soundfont samples


From: Reinhold Hoffmann
Subject: Re: [fluid-dev] parallel loading of soundfont samples
Date: Tue, 27 Oct 2020 09:14:56 +0100

We use SF3 files for some years now due to the reasons Marcus outlined below
and where faced with the same problem of long loading times. As a solution
SF3 soundfonts are loaded in the background where the app is already up and
ready for the user but the sound subsystem is not yet ready. 

Of course, such a solution only makes sense for apps where the sound
subsystem is a minor part and has not to be up at once.

Reinhold

-----Urspr√ľngliche Nachricht-----
Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=notation.com@nongnu.org]
Im Auftrag von Marcus Weseloh
Gesendet: Dienstag, 27. Oktober 2020 08:28
An: FluidSynth mailing list
Betreff: Re: [fluid-dev] parallel loading of soundfont samples

Thinking about this some more...

If I interpret your question as "What is the fastest way to load a
whole Soundfont on app startup?", then my answer would be: simply load
an SF2 file.

Loading an SF2 file is really *much!* faster than loading
Vorbis-encoded SF3 files. The SF2 loader grabs all sample data for all
samples in a single large read call. In contrast, the encoded Vorbis
samples get loaded and decoded sample by sample, data chunk by data
chunk. That alone will make it really hard to get to SF2 speeds, even
with multi-threaded Vorbis decoding.

Obviously I don't know your reason for using SF3 files, but my guess
is that it is to reduce download times of your app (the only real
use-case for SF3 in my opinion). Would it be possible for you to
convert the SF3 back into SF2 during the install process? Or convert
SF3 files into SF2 on first load and store the result in a disk cache
somewhere? Platforms with constrained disk space are rare these days.
And doing lots of work to decode something on every load of the app
seems wasteful, when you could simply store the decoded data at
virtually no cost.

Cheers
Marcus

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




reply via email to

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