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

[Marcus Weseloh]

Hi,

in addition to what JJC said, we should also take into account that
sample entries can point to arbitrary locations in the sample data
chunk. So it's theoretically possible that two samples point to the
same encoded ogg data, but use different parameters like loop
start/end. A parallel loading mechanism would have to either
deduplicate the sample entries list first, or live with the fact that
in some cases the decoding is done multiple times and only one result
is actually used.

I must admit I am sceptical if the effort of rewriting the loader is
worth it. It would be a major change to the current structure,
regardless if we try to parallelize just the decoding or the complete
soundfont loading. And if the simple OpenMP test that Tom has posted
is any indication to the real speedup, then I do wonder if a realistic
speedup would actually solve the problem that Hamish has.

Hamish, what loading time would be acceptable for your application if
you were to block until all soundfonts have loaded?

It would be a shame if we were to do all this work and end up with a
situation where you still prefer the asynchronous load because even a
1-2 second loading time is still too long for synchronous parallel
loading...

Cheers
Marcus

Am Mi., 28. Okt. 2020 um 22:16 Uhr schrieb Ceresa Jean-Jacques
<jean-jacques.ceresa@orange.fr>:
>
> >Currently, there are two problems: 1. The samplecache is guarded by a mutex 
> >that prevents naïve parallelization. 2. If we relax that mutex we get a 
> >strange race condition,...
>
> The whole fluid_samplecache_load() need to be atomic and isn't thread safe 
> without the mutex
>
> -get_samplecache_entry(), need the mutex
>
> -fluid_list_prepend(), need the mutex
>
> -entry->num_references++; need the mutex
> ...
>
> jjc
>
>
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev