How the JACK Sound Daemon is capable of running at 192kHz

Most of my Linux-computers have as their sound-server “Pulse Audio”. But specifically on my laptop named ‘Klystron’, I have set up the JACK Daemon to be able to run as an alternative, yet not to be running by default. I have performed experiments on that laptop, to confirm that I can launch this sound-server, using a GUI named ‘QJackCtl’, but have also had to make modifications to how this GUI executes commands from the user, so that its start-up pauses the Pulse Audio daemon, which has been able to resume successfully after I was done using JACK. Without such a detail, the attempt should not be made.

One fact which I can see in QJackCtl, is that JACK is capable of running at 192kHz, even though it has not interrogated any of the available devices, about their real capabilities are.

The reason this is possible is the fact that individual sound devices are just clients to that daemon, including any number of devices that act as sound-sources, rather than acting as sinks, i.e. that act as inputs rather than as one output.

I also own a USB-Sound-Device named the ‘Scarlett Focusrite 2i2′, which is mainly intended for use in sound capture, but which also has outputs intended for monitoring purposes.

If I was to run JACK at 192kHz, then one simple consequence of that would be, that zero actual sound-devices would remain compatible with it. As to how cleanly an attempt to connect to an incompatible device exits, giving error messages or crashes, I have not tested, because when I tested the Focusrite, I took into account the real limit of that device at 96kHz.

Similarly, the JACK Daemon runs with 32-bit linear precision by default. In this case, when we enable devices to act as clients, which are only capable of 24-bit sample-depth, which is common, the mismatch is safely ignored. JACK already sees to it, that the last 8 bits of precision get ignored.

Now, I could be cautious and worry, that because of errors in the Linux drivers, those last 8 bits somehow get mapped to a control register as an error. But then the simple way to test for that, was simply to send some 32-bit sound through JACK, to this output device. What I found when testing this, is that the basic operation of the Focusrite was not disturbed, even though my hearing was not good enough, to tell me when I had my Sennheisers on, whether in fact 24-bit precision was still working. I was mainly testing, that trying to send a 32-bit value, does not disrupt the actual operation.

‘QSynth’ is an additional GUI, which creates a software-synthesizer, that requires JACK. QSynth relies on the program ‘fluidsynth’, which is a Sound-Font Player. QSynth can easily be set to output at 32-bit sample-depth. However, even though ‘fluidsynth’ can be commanded to run outside a JACK session, its GUI ‘QSynth’ just does not display such an option.

But the noticeable deficiencies in the sound which QSynth outputs, are truly due to limits in the Sound-Fonts, which I am licensed to be using. Super-High-Quality Sound Fonts would cost a pretty penny, and I do not own any. However, It remains my assumption that QSynth will interpolate output samples, from samples and other data stored in a Sound-Font I supply, in a Mathematically-consistent way. It can do all this, because it exists purely as software, in which digits of precision do not state the same thing, as accuracy would.

My Sound-Fonts were compiled by experts, to play best at 16-bit, 44.1kHz. Yet when played at 96kHz, they do not produce an incorrect pitch. That would be a possible bug which my system does not suffer from. The GCD between 441 and 960 equals 3. Thus, even if I had mistakenly set the order of interpolation to ‘Linear’, which its QSynth GUI should not do, there would have been 320 output values, for every set of 147 input samples. That simply would not produce clean, binary fractions. Yet, 147 is further divisible by 7… Twice…

What this means is that for my purposes, some number of least-significant bits QSynth outputs, are similar to random sequences of ones and zeroes. And if this module offers a 32-bit output format, that format can be used to test the system for reliability. But then I will hear deficiencies in the resulting sound, that are not due to anything running at 24, let alone at 32 bits.

‘QTractor’ is another JACK client, that is a DAW with a GUI. However, that DAW has its own project format, from which the sample-rate and the bit-depth follow. To keep the software running reliably, I had set up a QTractor session to run in 24-bit, 96kHz format. But this also means that all the samples this program output, would have zeroes as their least-significant bits, regardless of what synthesizer-modules I might run within. QTractor does not even display any sort of message or complaint, when told to connect to a 32-bit JACK Session in this way.

So to test JACK and the Focusrite completely, I had to include output from something other than QTractor as well.

Further, my interest in QTractor has diminished in recent years, because on the laptop named ‘Klystron’, I now have a version of ‘Ardour’ installed, which is a DAW and which I custom-compiled. I compiled it to be able to run without JACK…



Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>