Skip to main content

Topic: WavPack branch for low-latency streaming applications (Read 1178 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack branch for low-latency streaming applications
Once in a while a developer will ask me whether WavPack might make sense for a streaming application. I usually refer them to this article where a group used WavPack for real time streaming over RTP with good results.

The problem is that unmodified WavPack is not particularly suited for low-latency streaming applications because it has been optimized for maximum compression through the use of long blocks (typically ¼ – ½ second) and so a large per-block overhead (64 – 128 bytes or so, depending on mode) is irrelevant. However, when relatively short blocks are desired (e.g., 128 samples in the Kurtisi paper above) this overhead becomes significant and greatly reduces the efficiency of the compression.

To better handle these applications, I have recently worked on a new branch of the WavPack code that is optimized for short blocks. This was accomplished by reducing the header overhead by about 2/3, to about 22 – 44 bytes, again depending on mode. These blocks no longer have enough information for accurate seeking, but this is not a requirement for streaming applications. The codec is completely incompatible with regular WavPack, and I have eliminated tagging capability, but in theory it should be possible to losslessly transcode the audio back into regular WavPack if that was desirable.

Just to be clear, this is not intended as a replacement for WavPack, and is only intended for streaming applications.

The source code is currently available here, although this is still very much a work-in-progress and the format may change. Unfortunately I have not built this natively on Windows, but the mingw builds seem to work fine.

Thanks, and hopefully someone will find this useful!

  • Fairy
  • [*][*][*]
Re: WavPack branch for low-latency streaming applications
Reply #1
Why would someone desire the use of low-latency lossless streaming? For voice communication there is a.f.a.i.k. no need for lossless transfer. For latency critical transfer you could suffice with an uncompressed stream.

I'm just curious who would use it.

I personally have had all my music in Wavpack, then transcoded back to FLAC because of compatibility issues when searching for other playback software. In a few months some servers (at work) will be replaced and the 'old' servers will become test servers for the IT dept. so I get a 'personal' server I can do everything I want with it (2 socket 12 core machine with 96GB RAM. This was a VM host. I'm thinking of using this machine to crunch all my music to WavPack in the highest possible comression ratio :)

Is there some extreme command line possible with even larger blocks and compression efficiency?

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
Re: WavPack branch for low-latency streaming applications
Reply #2
Yeah, lossless streaming does not make a whole lot of sense. The problem is that it's possible with pathological audio for lossless compression to actually inflate the data, so essentially there's no guarantee of compression. If the system can handle the max data rate possible, then what do you gain?

For that reason, most of the applications that consider WavPack are using the lossy mode (like the study I referenced above).

For maximum compression, the -hhx6 option gives you that. You could conceivably get slightly higher compression by increasing the block size, say back to the 1 second that 4.80 used (--blocksize=44100) and in fact you could do even better by actually using 4.80 which would eliminate the block checksum and a couple other bytes from every block. I wouldn't go that far though.... :)

  • Fairy
  • [*][*][*]
Re: WavPack branch for low-latency streaming applications
Reply #3
For maximum compression, the -hhx6 option gives you that. You could conceivably get slightly higher compression by increasing the block size, say back to the 1 second that 4.80 used (--blocksize=44100) and in fact you could do even better by actually using 4.80 which would eliminate the block checksum and a couple other bytes from every block. I wouldn't go that far though.... :)

That should be fun to play with. I'll experiment with that :) See how far I can push it :)