## libsamplerate

In This Posting, I gave much thought, to how the ‘Digital Audio Workstation’ named QTractor might hypothetically do a sample-rate conversion.

I thought of several combinations, of “Half-Band Filters” that are based on the Sinc Function, and ‘Polynomial Smoothing’. The latter possibility would have often caused a computational penalty. But there was one, simpler combination of methods, which I did not think of.

QTractor uses a GPL Linux library named ‘libsamplerate‘. Its premise starts out with the idea, that a number of Half-Band Filters can be applied in correct sequences with 2x oversampling or 2x down-sampling, to achieve a variety of effects.

But then, ‘libsamplerate‘ does something ingenious in its simplicity: A Linear Interpolation! Linear interpolation will not offer as clean a spectrum as polynomial smoothing will in one step. But then, this library makes up for that, by just offering a finer resolution of oversampling, if the client application chooses it.

This library offers three quality levels:

1. SRC_SINC_FASTEST
2. SRC_SINC_MEDIUM_QUALITY
3. SRC_SINC_BEST_QUALITY

Now, in This Posting, I identified an additional issue which arises, when we are doing an “Arbitrary Re-Sampling” and down-sampling. This issue was, that the source stream contains frequency components that are higher than the output stream Nyquist Frequency, and which need to be eliminated, even though the output stream is not in sync with the source stream.

To the best of my understanding, this problem can be solved, by making a temporary output stream 2x as fast as the final output stream, and then down-sampling by a factor of 2 again…

Sincerely,

Dirk

(Edit 07/21/2016 : ) The ‘GPL’ requires that this library be kept as free software, because it is in the nature of the GPL license, that any work derived from the code must also stay GPL, which stands of the “General Public License”.

But, because the possibility exists of some commercial exploitation being sought after, the Open-Source Software movement allows for a type of license, which is called the ‘LGPL’, which stands for the “Lesser General Public License”. The LGPL will allow for some software to be derived from the original code, which can be migrated into the private domain, so that the author of the derived code may close their source-code and sell their product for profit.

There exists a library similar to this one, that is named ‘libresample‘, with the express purpose that that one be LGPL code.

Yet, the authors of ‘libsamplerate‘ believe that this GPL version of the library is the superior one, which they would therefore have kept in the public domain.

## When Audacity Down-Samples a Track

In This Posting, the reader may have seen me struggle to interpret, what the application ‘QTractor‘ actually does, when told to re-sample a 44.1 kHz audio clip, into a 48 kHz audio clip. The conclusion I reached was that at maximum, the source track can be over-sampled 4x, after which the maximum frequencies are also much lower than the Nyquist Frequency, so that if a Polynomial Filter is applied to pick out points sampled at 48 kHz, minimum distortion will take place.

If the subject is instead, how the application ‘Audacity‘ down-samples a 48 kHz clip into a 44.1 kHz clip, the problem is not the same. Because the Nyquist Frequency of the target sample-rate is then lower than that of the source, it follows that frequencies belong to the source, which will be too high for that. And so an explicit attempt must be made to get rid of those frequency components.

The reason Audacity is capable of that, is the fact that a part of its framework causes a Fourier Transform to be computed for each track, with which that track is also subdivided into overlapping sampling windows. The necessary manipulation can also be performed on the Fourier Transform, which can then be inverted and merged back into a resulting track in the time-domain.

So for Audacity just to remove certain frequency ranges, before actually re-sampling the track, is trivial.

If my assumption is, that QTractor does not have this as part of its framework, then perhaps it would be best for this application only to offer to re-sample from 44.1 kHz to 48 kHz, and not the other way around…

Dirk

## A Note on Sample-Rate Conversion Filters

One type of (low-pass) filter which I had learned about some time ago, is a Sinc Filter. And by now, I have forgiven the audio industry, for placing the cutoff frequencies of various sinc filters, directly equal to a relevant Nyquist Frequency. Apparently, it does not bother them that a sinc filter will pass the cutoff frequency itself, at an amplitude of 1/2, and that therefore a sampled audio stream can result, with signal energy directly at its Nyquist Frequency.

There are more details about sinc filters to know, that are relevant to the Digital Audio Workstation named ‘QTractor‘, as well as to other DAWs. Apparently, if we want to resample an audio stream from 44.1 kHz to 48 kHz, in theory this corresponds to a “Rational” filter of 147:160, which means that if our Low-Pass Filter is supposed to be a sinc filter, it would need to have 160 * (n) coefficients in order to work ideally.

But, since no audio experts are usually serious about devising such a filter, what they will try next in such a case, is just to oversample the original stream by some reasonable factor, such as by a factor of 4 or 8, then to apply the sinc filter to this sample-rate, and after that to achieve a down-sampling, by just picking samples out, the sample-numbers of which have been rounded down. This is also referred to as an “Arbitrary Sample-Rate Conversion”.

Because 1 oversampled interval then corresponds to only 1/4 or 1/8 the real sampling interval of the source, the artifacts can be reduced in this way. Yet, this use of a sinc filter is known to produce some loss of accuracy, due to the oversampling, which sets a limit in quality.

Now, I have read that a type of filter also exists, which is called a “Farrow Filter”. But personally, I know nothing about Farrow Filters.

As an alternative to cherry-picking samples in rounded-down positions, it is possible to perform a polynomial smoothing of the oversampled stream (after applying a sinc filter if set to the highest quality), and then to ‘pick’ points along the (now continuous) polynomial that correspond to the output sampling rate. This can be simplified into a system of linear equations, where the exponents of the input-stream positions conversely become the constants, multipliers of which reflect the input stream. At some computational penalty, it should be possible to reduce output artifacts greatly.

## Running JACK side-by-side with PulseAudio

On the laptop I name ‘Klystron’, the default sound server is PulseAudio, as is often the case with desktop setups. And yet I found myself installing a lot of Linux music-authoring software on it, only to find that in order to get the full benefit of that, we need to be able to use JACK as our sound server. This was not really a new observation.

Specifically, in order to allow ‘Rosegarden‘ and ‘QTractor‘ to work fully, we need to have JACK. Without JACK installed, Rosegarden will complain when run that it can produce no sound output, but is still installable. And QTractor has the actual JACK daemon as one of its install dependencies. More generally, I did not find any DSSI hosts, that could run without JACK.

Under Linux, ‘LADSPA’ and ‘LV2′ are effect-plugin-APIs, which can also be used from applications such as ‘Audacity‘, while ‘DSSI’ is The Linux instrument plugin-API. One needs DSSI for any type of plugin, which receives a MIDI sequence and plays that, regardless of whether the MIDI-sequence came from a sequencer, or from a live, real controller-instrument.

And so I took the time last night, to set up the actual JACK daemon – not just its libraries – to coexist peacefully with PulseAudio.

The approach I took, was to install QJackCtl, a GUI that allows the user to start and then stop JACK, and that allows the user to configure this starting and stopping to taste. In order for JACK to do what it is supposed to do, I needed to change the ‘Server Path’ with which QJackCtl launches the daemon, to


pasuspender -- jackd



This field within QJackCtl tells the GUI what command to execute, to launch JACK, and has recently been renamed to the “Server Prefix”. Nevertheless it can still be customized in this way.

pasuspender‘ is a utility that comes with PulseAudio, which tells this server to suspend its access to the sound devices, for as long as the program is running, which follows as its command-line parameter. The two dashes are important.

I found, that although ‘pasuspenderdoes suspend PulseAudio, it also fails to resume this service, once the program has terminated, that was given as its parameter. I suspect that this happens, because QJackCtl terminates the command


pasuspender -- jackd



instead of actually terminating the child-process


jackd



Thus, pasuspender cannot act on ‘jackd‘ having exited, because the parent process was terminated, right along with the child-process. And so there is another field within QJackCtl, where I get to specify a post-shutdown script for JACK, where I simply inserted the command


pasuspender /bin/true



This second invocation of ‘pasuspender‘ exits without error, and actually causes PulseAudio to resume.

It is important to give this command in the correct field. I.e., If we gave this command in the pre-shutdown field, we would get a mess.

Now, this is a configuration which allows me marginal use of JACK, and while I have QJackCtl running, PulseAudio will just not work. There exist some script-artists, which will go further, and who have written more-complex scripts for QJackCtl to execute, and that will insert JACK as a back-end, for PulseAudio to continue sending sound-output to, once JACK has been launched. And then those scripts will also reverse this setup, and set PulseAudio back to running in its default mode, once JACK has been terminated.

I had two reasons not to go this route.

1. On my systems, the back-end which PulseAudio uses are fragile. While they can be reconfigured, doing so messes up the PulseAudio instance running, until my machines are rebooted again. Changing this configuration within a session is poorly advised, on my setups.
2. Trying to do so struck me as somewhat ambitious, and there are many ways in which an attempt can get stuck, due to minor logical errors between the scripts. The fact that I needed to execute

pasuspender /bin/true



at shutdown, to get PulseAudio truly working again, reminded me that unexpected logic glitches can come up, and that maybe I should not try to get JACK and PulseAudio working concurrently, part of the time. If this was a full-time setup, this option might actually make sense, but for temporary use – controlled with some scripts – this option seemed to make little sense to me.