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.cer...@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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
