Use wavpack for cache compression.

[rhpvorderman]

A couple of observations:

• GrandOrgue is well designed and very hard to CPU bottleneck, even when playing a large organ such as the Friesach with all registers pulled and comperessed in-memory storage on.
• Cache loading causes notable waiting times even on a nvme SSD.
• The friesach cache file is about 12 GB and takes 17 seconds to load on my PC. (Pcie 2.0 with a x4 nvme disk).
• When I open and close grandorgue the organ loads in less than 2 seconds, because all 12 GB fits in the linux fs cache. This is with compression on. So the wavpack compression surpasses 6 GB/s when loading the cache in memory.
• The in memory size for the friesach with compression on is just 1,7 GB.
• The compressed cache takes 17 minutes to compress and 2 minutes to load. Severely cpu bottlenecked, yet the filesize is approximately 8 GB.

I think GrandOrgue would benefit from GoSoundingPipe's saving and loading cache actions always going through wavpack.

• Caches will be significantly faster to load, since there is less data from disk to be read.
• caches will be significantly faster to write for the same reason.
• in theory, when the in-memory compression is chosen, decompression is not even needed at the loading stage.

Given wavpack's tremendous speed, I doubt it will be a bottleneck.

Is this a feasible idea?

[rhpvorderman]

After compressing all friesach data with wavpack's default settings the files are 5,5 GB. So that must mean this is probably implemented. Otherwise the cache could never be 12 GB as the uncompressed data is 17 GB. Oh well.

[oleg68]

1. The cache was designed for speeding up loading from spinning HDDs, not SSDs.
2. Loading from the cache utilises only one cpu thread while loading from original samples can utilise more cpus. Reading several sample files in parallel may increase loading the organ. So I recommend you to disable cache.
3. If the Pcie 2.0 throughput is your bottleneck, you may try to compress the samples with vawepack as for the .orgue files. GrandOrgue supports using .wv files as well as .wav files.

[bonninr]

I'll chime in to ask about a wavPack feature: lossy compression. Is the saving or loading from lossy samples supported? Thanks!

[rhpvorderman]

Thanks @oleg68 . I did a few tests:

• loading from wavpack files (5,5 GB). Around 2 minutes, cpu all cores at 100%.
• loading from wav files (17GB). Around 1 minute, cpu all cores at 100%.
• loading from cache (12GB). Around 15 seconds. Cpu cores barely used. Since the cache seems to be an almost pure memorydump it loads much faster than the other options.

The cache is therefore also very beneficial in my SSD scenario. My system has a i5-2500S (four cores, no hyperthreading), so the cpu is not that great. Still I feel on more modern platforms the cache will also be faster than loading if fast PCIe 4.0 SSDs are used.

I will close this issue as the cache already uses wavpack compression. GrandOrgue is so extremely well build and optimised. Thank you so much for building and maintaining it!

[oleg68]

@rhpvorderman There are more options to try:

• Enable/Disable Loseless compression
• Enable/Disable Compress cash

[rhpvorderman]

• The organ only fits compressed. It requires 12 GB compressed and much more than that uncompressed. My system only has 16GB. I can imagine if the compression does not need to happen, loading from the filesystem can be faster than loading from the cache.
• Compressing the cache takes a very long time. Loading from the compressed cache also takes about two minutes. The CPU is the bottleneck here.

So in my case loading from the cache, which does not require any CPU load is the fastest. I am storage bottlenecked in that case, but I managed to wiggle a PCIe nvme SSD in the system (thanks to a mxm to pcie converter card) and now the organ loads in 15 seconds. I am quite happy with that!