Technical info


ConvoFS run on Linux machines/Linux based Synology NAS devices and is implemented using the “FUSE” software for running file systems in user space. The core services (“daemons”) are written in the Perl language, and the user interface is in PHP.

ConvoFS mirrors the directories/files in your music collection file tree, but intercepts read operations to FLAC files replacing the data return with convolved data. That’s - subject to minor delays - basically transparent.

Overly simplified: To make things transparent, ConvoFS translates the byte offset of the read operation into a FLAC frame number and convolves that frame.

To facilitate this translation, ConvoFS returns FLAC music data as verbatim (i.e. uncompressed) frames. Such reencoding is the case for all 3 ConvoFS operational modes. Also, 16-bit music is transcoded to 24 bits which is best practice in DRC setups and not dictated by the ConvoFS design. The transcoding increase the needed bandwidth between your music server/NAS and playback device. 44/16 music will need 2.1Mbit continually, and 192/24 music will need 9.2 Mbits etc, which may trigger a need to use cabled connections rather than WiFi for your streamer. Sound-wise, one can argue that using uncompressed FLAC is an advantage. Apart from a header and a couple of frame headers, this is WAV which many prefer to FLAC.

As mentioned, ConvoFS does not create another, convolved copy of our music collection, only a temporary cache. It does, however, create a preprocessed copy of the FLAC headers/metadata of your music. The preprocessing means fixing the bit width for 16-bit music, and body building padding info so that the entire FLAC header is always a multiple of 64 kbyte large. It is done to make Minim Server indexing fast.

Decoding a log+config bundle

The log bundles are heavily compressed but not encrypted. To access the contents of a bundle from a Windows PC, the easiest way is to install the program 7Zip which is for download at http://www.7-zip.org/. I believe that Mac (and Linux) computers can access them directly. If you’ve selected logging level 2, prepare for a lot of info about the inner workings of ConvoFS.

Flow chart of the ConvoFS internal processing pipeline

Sometimes a picture is in its place. Here’s a diagram showing processing paths internally in ConvoFS.


And here’s a more detailed one elaborating on the convolving pipeline:


The triangles are signal entry/exit points.

Technicality: avoiding ‘ticks’

ConvoFS partitions a music file into blocks of up to 20 seconds playing time each, convolving blocks separately, and gluing together the resulting blocks. That’s bound to produce annoying ‘ticks’ at the block boundaries. Indeed, ConvoFS development was during one phase stalled for a long time due to those frustrating artifacts. The way it is solved is to convolve an additional two seconds of sound before and after each block, discarding the extra convolved data before the gluing process. The attentive reader will notice that this strategy cannot be applied to track boundaries in live recordings. The observation is correct, and the architecture of ConvoFS makes it next to impossible to fix. But with most recordings, it is in practice, not a problem. Anyway, an occasional small tick is tolerable. One each 20 seconds was not.

Talking of ticks, there’s also an issue with DSD upsampling of convolved PCM (FLAC) data. ConvoFS uses the gluing technique described above to assemble the convolved blocks of PCM data. But due to the nature of the DSD format a related - and worse - problems pops up when the upsampled blocks of DSD data are assembled. Here, ConvoFS applies another little hack – at the end of each block, the sound is quickly faded down to zero volume and at the beginning of the next block increased back up to the desired level. This trick currently takes 2x3 ms. I can still hear an occasional small tick.