Dealing with RAM/swap "lag" spikes using samplers

[sneakernets]

This is a bit of a tough one to explain but I will try my best:

I am working on a live music gig project using the RPi3 as a "synth module" for my MIDI keyboard. I'm hoping, in future, to use this setup as a synth exclusively, because synths are quite expensive these days...

None of the software I'm using currently is CPU bound at all (20-40% CPU on one core may be the most I've seen thus far), but memory is a completely different story. I have many sample banks stored on external storage, most quite large in size. I don't use these all at once, but the one I do use the most, the piano bank, is 512 MB Of course, that's all Linear PCM data, which is effortless to spit out of speakers.

The problem appears when I'm in the process of switching banks, or layering two banks, and I think we can all see why. When playing live, we can't assume we're only going to use just a few samples, so that 512 MB chunk is read into RAM. Soon enough, I'm hitting the limits of RAM, and swap kicks in. I wouldn't have issue with this if the operation didn't take everything down with it as it writes to the SD Card, including any other module that doesn't use samples. I don't want to write to the SD card anyway, at least not that much!

So in a nutshell, I'm dealing with massive memory pages being kicked in and out, which is tolerable as long as I do not hit the "edge". Besides choosing some smaller sample banks (which I really don't want to do), are there any solutions to dealing with these "spikes"?

I have googled around and found some mentions on "Virtual Memory Compression" for the Linux kernel, and that just might be the golden ticket. I'm competent in the terminal, so no solution is too difficult to try, I just don't know the best path to take given my situation. Anything to reduce or eliminate the lag as much as possible would be great.

Regards,
Sneak

[steveb4pi]

tmpfs is a RAM disk system that might help == you read your sampes off SD and compress them to a folder in tmpfs from where it should be fast enough to decompress 'on the fly' as needed..

You could maybe pipe the files via 'gzip' yourself (to compress/decompress under your own control) or use some means to define a 'compressed folder' (a quick Google turned up https://github.com/tex/fusecompress which looks like it might do the job, but see also here :- http://unix.stackexchange.com/questions ... pfs-folder (your samples can be pre-compressed into a 'static image' so 'squashfs' might be ideal)

[excors]

If you're allocating memory then reading the files into it, it might make sense to use mmap instead, which maps the file's contents directly into virtual memory. When you first read from a 4KB page, it'll get loaded from disk then stored in the OS's page cache. If the OS starts running out of RAM it can simply drop pages from the page cache - it doesn't need to write back to disk since it knows the data's already there in the file you mapped. You'll still have the unpredictable cost of reads but will avoid all the swap-writing.

Or you could store the samples in memory in a compressed audio format (Vorbis, FLAC if you want lossless, etc), and decompress on the fly as you're playing them. I think gzip is unlikely to compress audio effectively (because audio doesn't really have the repetitive byte sequences that gzip is designed to cope with), and zram (for virtual memory compression) uses something like LZ4 which has even worse compression ratios (its only advantage is speed), so they seem unlikely to help much.