https://bugs.winehq.org/show_bug.cgi?id=30639
Kai Krakow kai@kaishome.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai@kaishome.de
--- Comment #56 from Kai Krakow kai@kaishome.de --- Shouldn't it be relatively simple to just spawn more threads and do parallel resampling by splitting the buffer in half? A heuristic could do this, i.e. if the current buffer took more than 50% CPU time in single thread, and at the same time we have less than 50% CPU usage across the full CPU, we could split the buffers. This cycle could repeat and split buffers in half again if the heuristic barrier is crossed again. A protection would kick in if more than 50% of the CPU threads are reached, i.e. we'd use 4 threads max on a 8-core CPU.
At the end of one mixing cycle, the threads will be synced and maybe we'd need to calculate a remaining mixing window at the adjacent borders of the buffers based on the algorithm used.
This should be pretty simple to implement in a first step by hard-coding the heuristic to use two threads. But spawning and joining threads may have high overhead, so that should be done once at the heuristic barrier so we'd not recreate threads on each buffer cycle.
Without having looked at the code, it seems it already has one worker thread. It could be enhanced by simply putting additional offset and length values into the worker struct, and some boilerplate code around to re-sync the threads to the merged buffer.
Also, I'm not sure if there's an effect library involved which would apply reverb or similar effects. Using parallel threads here is probably not possible. We could still split threads by other parameters, tho, which was outlined in some comments already (e.g. by sample rate) but that may not reliably lower the time needed, it may even potentially have an inverse result because we'd need to combine the groups in a final pass.