2009-02-21

Sonic Visualiser is a recent discovery for me, and I’m absolutely hooked on its breathtaking spectrograms. Its melodic range spectrogram, when combined with A-B repeat playback and tempo adjustment, has proven to be the perfect tool for learning to imitate new mandolin parts.

Its synchronous audio playback and spectrogram display can, however, be annoyingly slow at times. Disk IO appears to be the limiting factor.

From the Sonic Visualiser website,

The work Sonic Visualiser does is intrinsically processor-hungry and (often) memory-hungry, but the aim is to allow you to work with long audio files on machines with modest CPU and memory where reasonable. (Disk space is another matter. Sonic Visualiser eats that.)

Sonic Visualiser saves on RAM usage by keeping a huge disk cache. On faster hard drives this may not pose a problem, but my laptop’s 5400 RPM disk just can’t deliver the cached data fast enough during synchronous playback.

Since I do have oodles of free RAM just itching to be put to good use, I would like to make the reverse trade-off to sacrifice memory consumption in return for faster cache access. Sonic Visualiser doesn’t appear to have a built in way to do this, but there’s an old trick we can use to accomplish the same effect:

tmpfs filesystems appear as normal disk space, but behind the scenes are stored primarily in RAM. If Sonic Visualiser’s cache file directory is put on a tmpfs filesystem, it will have the same effect as storing its cache in RAM.

With the following entry in /etc/fstab,

# Faster cache location in RAM
fastcache   /home/ak/.fastcache tmpfs   size=1600M,noauto,user,exec,uid=1000,gid=1000 0 0

the command

mount /home/ak/.fastcache

will create an empty tmpfs filesystem for use. All that’s left to do is tell Sonic Visualiser to keep its cache in that new location.

When you’re done, use the command

umount /home/ak/.fastcache

to destroy the tmpfs and free memory.

Quick stats to get a feel for how much space might be needed:

Don’t worry about setting the maximum size too high. Memory is only allocated for tmpfs as it grows in size, so RAM isn’t wasted in that regard. Also, if there isn’t enough free RAM to hold the entire tmpfs, the least-used parts will be stored in swap space instead. Once in swap space, the cache will lose its speed boost but continue to function up to its maximum size.

Thanks go to stevenrobertson for the idea inspiration.