I'm pretty sure there won't be too much wide interest in this, but I have received several queries lately about using WavPack in low latency applications. Since the WavPack algorithm normally uses only backward prediction it should be ideal for this, but the WavPack block format was a limiting factor.

To respond to these possible applications, I have created an experimental version with a modified block structure that allows for very low latency. This version works well down to even 50-100 samples per block, and supports the pure lossless, lossy, and hybrid lossless modes. Besides the low latency advantage, this format could also be used for encoding applications requiring a very small memory footprint.

I put some more technical info here and the source code can be obtained from SVN here. Perhaps this will be useful to someone.

David

I don't understand, do you still need at least 1000 samples to start decoding? What is the advantage over making all blocks that size, and transferring data as soon as possible for low-latency applications?

low latency applications are most of the time related to (realtime) communication. In these scenarios you expect that the transmission is not delayed for long (being long aroud 100ms and 500ms being nearly unusable)

Encoders use to work in blocks of data instead of byte by byte. If the block needed is small, it means that the time to wait for those bytes is smaller, and thus the delay from the recording to the reproduction is lower.

Said that, i'm not sure about the 1000samples requirement that you mention above. (obviously if the decoder needs them to start decoding, it is necesarily the minimum delay. Yet, an application could simply discard these first 1000 samples and start reproducing at the 1001 sample).

The standard code works with 50-100 samples per block and would have been fine for low latency apps, but because of the overhead of the header and the state information required to start decoding, it's not efficient in overall bitrate. The 1000 samples mentioned in the document is simply an arbitrary point where the efficiency starts to become borderline, but you can actually specify 1 sample per block if you want to!

For this experimental version, the header and state data is only transmitted every 16th block (for example), thereby increasing the efficiency to the point where it's actually usable with smaller blocks. This means that 1 in 16 blocks is going to be somewhat bigger than the others, but that's okay. If the stream is interrupted somehow, the decoder must wait until one of the larger blocks arrives to get all the information required to begin decoding again.

For the applications I was asked about, latencies of just a few milliseconds were desired because the codec was only one part of the whole chain of latency producing steps.

Thanks for the explanation!