Hi folks, here's the latest fre:ac development status update covering the months of June to August of 2019.

Yes, it's again been three months already since the last update. While my goal is to write monthly reports, my free time is limited and especially in summer, working on fre:ac is competing with other activities like cycling and kayaking, so needless to say it's suffering a bit. The upcoming rainy autumn and cold winter should lend themselves better to spending time on open source projects though. ;)

As already teasered in the previous report, I have some exciting news today and it's about fre:ac's I/O performance.

I/O performance improvements

Doing most of my testing on a relatively fast SSD, I usually found fre:ac's I/O performance to be just fine. It turned out, however, that when putting the output folder on an HDD drive, it can be horribly slow.

This is especially true when doing parallel conversions with lots of threads and writing to an internal HDD. A user with a 16 core / 32 thread Threadripper system approached me, claiming the conversion performance would not scale beyond 8 threads and asked me to have a look at that.

Well, I did and found that while performance was OK when the output folder was on an SSD, it could be more than 20 times slower when writing to an HDD. Looking at the I/O performance in Task Manager revealed that fre:ac was writing a mere 6 MB/s when the disk should be capable of much higher throughput.

The reason turned out to be an oversight of mine when implementing the audio file I/O layer. While fre:ac's I/O system uses buffered I/O in most cases - data is collected in a buffer first and then written in larger chunks - this was not true for most audio data writing (due to a lower - closer to metal - layer being used there). For the low level calls used for writing audio data, buffering was not enabled, leading to audio data being written in many small chunks and congesting the operating system's I/O queue.

Fixing this by enabling buffering on the low level I/O calls instantly improved performance by a huge margin. Here are some numbers for before/after performance with different target formats:

Converting 2586 mixed songs to MP3

Converting 2586 mixed songs to FLAC

So we're looking at a 4x performance increase when writing small (MP3) files to an HDD and up to 20x speed-up with large (FLAC) files. And even when the output location is on an SSD we are seeing more than 2x improvement in some cases. I did see even higher performance gains when converting a smaller number of files, as disk and OS write caches have a larger effect on the result in that case.

If you are on Linux, you can already try these improvements with the continuous AppImage builds or the edge channel Snap.

Multi-threaded adding to joblist

Sometimes, thinking again about a feature previously thought to be difficult to implement will bring up new ideas for a simpler approach. In June, a user brought up the topic of using multiple threads when adding files to the joblist. While I thought about that before, I deemed it too complex to realize in the fre:ac 1.1 development cycle - it was thus on my list for possible 1.2 features.

Thinking about this again, however, I quickly came up with an approach much simpler than my previous ideas. In short, the algorithm assigns tasks to threads in a round-robin manner while the actual adding to the joblist is still done in a single management thread. This is a bit less efficient than an ideal solution, but is so simple in fact, that it could be implemented in just a few hours and without much risk to break anything else in the program.

So this is now implemented and in combination with the aforementioned I/O improvements and some other optimizations, it can greatly speed up the time needed to add files to the joblist. Adding my test library of about 2600 songs in different formats now takes roughly 10 seconds with these changes compared to about 2 minutes with the 20190423 release:

I included the 1.0.32 release in this comparison as it was actually faster than the 20190423 snapshot. This is due to the development releases reading a lot more information (like cover art) from the files. Also, adding the tracks to the tag editor in addition to the joblist takes some time, so it's good to see the new code outperforming any previous version of fre:ac.

As with the I/O improvements, Linux user can already try these changes with the continuous AppImage builds or the edge channel Snap.

Dark mode on macOS

In July and August, I was mostly working on implementing dark mode support for the macOS version of fre:ac.

There actually are two aspects to this. The first being actual work on support for dark color schemes - some elements had colors hard-coded to a value fit for a light theme only. The second - and vastly more difficult one - is reworking the drawing code architecture of the macOS version. The old drawing code used some deprecated patterns no longer allowed in modern macOS. Applications built using an older SDK and supporting only light mode can run in a compatibility mode, however, which is what fre:ac is still doing in the latest release. As soon as you declare dark mode support though, your application will no longer run in compatibility mode and will have to implement the latest drawing paradigms.

So this took a while to implement and is not quite finished yet, but should be fully integrated within the next one or two weeks.

Smaller improvements

• Multi-channel Monkey's Audio
  The Monkey's Audio codec got support for multi-channel audio in a recent release and fre:ac now supports that.

• Tagging improvements
  Some tag fields previously only available in ID3v2 tags are now supported in a wider range of tagging formats. This mostly effects the Mix artist, Grouping, Disc subtitle, Copyright and Catalog number fields.

• Bug report and feature request templates
  The fre:ac issue tracker on GitHub now has templates for bug reports and feature requests which should help improve the quality of issue descriptions and ultimately make it easier and quicker for me to help.

Besides these improvements, several bugs have been fixed in the past three months. I'm working towards publishing a new release, but cannot give a definite time frame for it yet.

That's it for this issue. Make sure to come back here for the next one (hopefully in one month ;)).