Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: parallel encoding (Read 9467 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

parallel encoding

Is it true that WavPack isn't suitable for parallel encoding?

http://www.hydrogenaudio.org/forums/index....st&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.

parallel encoding

Reply #1
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.

 

parallel encoding

Reply #2
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.

parallel encoding

Reply #3
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?

parallel encoding

Reply #4
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.