Is it true that WavPack isn't suitable for parallel encoding?
http://www.hydrogenaudio.org/forums/index....st&p=730219 (http://www.hydrogenaudio.org/forums/index.php?showtopic=64628&view=findpost&p=730219)
If not, are there any plans to make it suitable in the future? I would love to see a GPU encoder for Wavpack.
It's doubly true for WavPack. It uses a set of decorrelation passes to "squish down" the input signal. The input of each pass is the output of the previous pass, so there's no possible way to do all the passes in parallel. Then, when encoding the bitstream sub-block, the median values are adjusted for each residual value, so those can't be processed out-of-order either. The only gain I can think of would be to process multiple blocks in parallel, but compression would suffer slightly since one wouldn't be able to wrap any decorrelation pass values from one block to the next so encoding would have to start "from scratch" each time.
In any case, WavPack encoding is already pretty fast, so there's less need of parallel processing.
Wow, tuffy, you certainly are familiar with the WavPack code!
Yes, unfortunately, WavPack was not designed with parallelization in mind. However, I think that there might be some things that could be done (although some would be pretty complex).
The one part of WavPack that is pretty easy to parallelize is the left and right channels can be combined with SIMD, and this is implemented in MMX macros for 24-bit encoding. I have looked at the code generated by this and think there might be room for improvement in hand assembling, but I have not tried it. I would be nice if it could be sped up enough to be faster with 16-bit data.
For lossless encoding it should actually be possible to use multiple threads to perform the multiple passes of the decorrelator...you would just have to make sure that the processors for subsequent passes stayed behind the previous passes (and for decoding this can be done “in place” as long as subsequent passes stay 8 samples behind).
It’s also true that the entropy encoding cannot be parallelized but, again, a thread doing that could trail the last decorrelation thread through the buffer. Also, the information needed to efficiently start decorrelating the next block is available as soon as the decorrelation of the previous block is done, so that could occur at the same time as the entropy encoding of the previous block.
Of course, because of the feedback from the entropy encoder during lossy encoding, all of this only applies to lossless mode.
I don't want to open a new thread about this since it's kinda a similar topic, so i'll just ask here. Is the fact wavpack.exe is only using one thread the reason why it doesn't use my cores completely? No cores get over 50%, I'm thinking that's windows's scheduler distributing a load of 100% among cores, would that be correct?
I don't want to open a new thread about this since it's kinda a similar topic, so i'll just ask here. Is the fact wavpack.exe is only using one thread the reason why it doesn't use my cores completely? No cores get over 50%, I'm thinking that's windows's scheduler distributing a load of 100% among cores, would that be correct?
Yes. With some work wavpack.exe
could use multiple threads (and thereby more than one core at a time), but that has not been done.