> So in my opinion, doing the work to make the sample cache and maybe even the whole soundfont loading mechanism work in parallel seems like a good idea and worth the effort.
We need to be careful, as the soundfont loading is exposed via the API. Breaking changes should be avoided. Also, we could easily run into premature optimization: I don't think it would be worth to parallelize the loading of SF2 files, as they are IO-bound. That's why I vote to concentrate on SF3 in a first step. That is, before rewriting everything, find out how we can use the existing architecture. As we saw, the problem currently is the shared sffd file pointer. What we need is a way to store the read/write file pointers directly in the sfvio_data_t struct. To do this, I suggest we drop the idea of using fopen() and friends, and directly mmap() the file. (We'll surely find an equivalent implementation for Win32). Using pure char* under the hood allows us to keep track of their seek offsets (given by sfvio_seek()) individually for each thread. And ofc, the public sfloader API would remain unchanged by this. Also, we need to clarify the parallelization framework to use. I vote for using OpenMP Tasks. This requires an OpenMP 3.0 compliant compiler. All modern compilers fulfill that... except Visual Studio, whose support for C and OpenMP dates back 20 years ago. As alternative we have hand-written thread handling stuff provided by glib or C++11. Frankly, I don't think this is worth the effort. Tom _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
