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

Most of my Linux-computers have as their sound-server ““. But specifically on my laptop named ‘‘, I have set up the 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 ‘‘, but have also had to make modifications to how this GUI executes commands from the user, so that its start-up pauses the , which has been able to resume successfully after I was done using . Without such a detail, the attempt should not be made.

One fact which I can see in , is that 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 ‘‘, which is mainly intended for use in sound capture, but which also has outputs intended for monitoring purposes.

If I was to run 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 , I took into account the real limit of that device at 96kHz.

Similarly, the 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. 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 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.

## Successive Approximation

While Successive Approximation is generally an accurate approach to Analog-to-Digital conversion, it is not a panacea. Its main flaw is in the fact that the D/A converter within, will eventually show inconsistencies. When that happens, some of the least-significant bits output will either be an overestimated one, followed by nothing but zeroes, or an underestimated zero, followed by nothing but ones.

Although circuit specialists do what they can to make this device consistent, there are quantitative limits to how successful they can be. And, whether 24 bits can be achieved depends mainly on frequency. In analog circuits, voltages tend to zero in on an ideal voltage exponentially, even when there is no signal-processing taking place. So the real question should be, ‘Can 24 bits still be achieved, far above 48kHz?’

And, if we insist that the low-pass filter should be purely numeric, we are also implying that one A/D conversion must be taking place at the highest sample-rate, such as at 192kHz, while if the low-pass filter could be partially analog, this would not be required.

Dirk

## My Opinion on the Opinion of Chris “Monty” Montgomery

Chris Montgomery is the Audio Expert, who invented the OGG Vorbis codec. That gives enough reason to accredit him with good advice. I recommend that my readers read his advice here.

I did read the whole thing, but have three comments on it:

1. The Author suggests that 16-bit sample-depth offers a de-facto solution to the limits in dynamic range, simply due to the correct application of dithering. If I cannot trust my hardware to perform correct low-pass filtering, why on Earth would I trust it to perform correct, 16-bit, audio dithering?
2. The Author explains the famous loudness curves, that define threshold of perceptibility, as well as the higher threshold of pain. What he fails to point out is that these curves assume, that the sound being tested for, is the only sound being played over the headphones. If there is another, background sound being played – i.e. the current loudness-level already higher than zero – then the threshold of perception for a given test-sound, is higher – requires a higher level, for that test-sound itself to be heard. Yet, this level is still lower, than the peak level of the background sound. People who design codecs know this, as I am sure the author does. It is the threshold of perceptibility next to a background sound – not the absolute threshold – which gets used in the design of codecs.
3. The Author suggests it would be a misuse of his codec, to encode discrete multi-channel sound. And one reason he states, would be the waste in file-size, while the next reason he states, would be the fact that sound jumps to the nearest speaker, when they are all encoded that way.

This last observation strikes a cord with me. I have already noticed, that OGG Files do allow numerous channels to be encoded in parallel, but that if we exceed 2, we lose the benefits of Joint Stereo. By itself, this does not really count against this Author, whose codec therefore does not offer explicit surround-sound. But the possibility is very real, that the localization of sound will jump to the nearest speaker, if the listener moves and the sound was encoded that way. It is entirely possible, that purposeful encoding of surround-sound by the (competing) AC3 or the AAC codecs, reduces this risk.

But then I would suggest an alternative approach, to people who do not want to use the proprietary codecs, yet who wish to encode their movies with surround.

There exists the Steve Harris LADSPA plug-in library, which includes a matrix encoder for Pro Logic. This matrix encoder accepts 4 input channels, one of which is the surround channel, and outputs 2 stereo channels.

Further, the circuitry must exist someplace as well, to accept 2 stereo, 1 center and 1 surround-channel, and to encode those in real-time, so that the surround-effect can be played back over 6 speakers.

• In principle, it should be possible to OGG-compress 4 channels and not 6, so that these channels can be used as inputs, to a matrix surround-system, like to the LADSPA plug-in, so that listenable surround will emanate from all speakers. Does Audio Software exist, which applies the LADSPA plug-in in real-time?
• Alternatively, it might be possible to mix down Pro Logic sound into Stereo using the Steve Harris plug-in, and then to use FLAC on the resulting stereo.

BTW: What the Author mainly writes, is how incorrect it would be for pure listeners, to download their music in 24/192 format. He does not actually write, that Music / Sound Authors should avoid recording in this format. And so one fact which I have observed, is that there exists a lot of Audio Software – such as – that stores its sound in some higher, internal format, but which, when instructed to Export that to a 16-bit format, offer Dithering as an option.

This is possible because the Application is numeric and not physical. Thus, If I had used my USB-sound-device to record in 24-bit, I could next Export the finished sound tracks to 16-bit:

But, It would also seem that Chris Montgomery equates the use of such technology, as only being suited for Professionals. I am not a professional, and do not have the extremely expensive tools they do. Yet, I am able to author sound-projects.

Dirk

## A Note on FLAC -Compressing 24-bit

One note which I had commented about before my blog began, was that if authors decide to capture sound at 96k samples /second, the resulting sound should compress well using FLAC.

But now that I have experimented with ‘QTractor‘ and an external sound card, I have realized that we will probably also be capturing that sound in 24-bit sample-format, instead of 16-bit. And the sad fact is, that FLAC will not compress the 24-bit format as well, as it did 16-bit.

The reason seems clear. Using ‘Linear Predictive Coding’ means that FLAC will be able to predict the next sample in a set of so-many, to maybe 8 bits of precision, except that the next sample will always deviate from this prediction by a small residual. So 8-bit sound should compress brilliantly.

But then with 16-bit, the accuracy of the encoding stays the same. So again, the ‘LPC’ is really only 8-bits accurate at best, meaning that we get a larger residual. The size of that residual is what makes up most of a FLAC File.

Well at 24-bit, again, the LPC will only predict the next sample, accurately to within 8 bits. And so the residual is likely to be twice as large, as it was with 16-bit, completing 24-bit accuracy this time. We are not left with much compression then.

When I recorded my 14-second sound session the other day, I selected FLAC as my capture file format. I had a noisy air-conditioner running in the background. Additionally, the compression level defaults to Fastest, because the file needs to be written in real-time, and not chewed on.

At 96 kHz, 24-bit stereo, raw audio will take up about 4.6 mbps. At 44.1 kHz, 16-bit stereo, raw audio takes up about 1.4 mbps.

Well I was capturing to a stereo FLAC File, but was only using one channel out of the two. So the FLAC File that resulted, had a bit-rate of 2.3 mbps. This means that FLAC recognized the silent track and used ‘Run-Length Encoding’ on it, but that was about all this CODEC could do for me.

Now, we do have a command-line tool which will-re-compress that file:


$flac -8 infile.flac -o outfile.flac$ flac -8 infile.flac --channels=1 -o outfile.flac
\$ flac -8 infile.flac --channels=1 --blocksize=8192 -o outfile.flac



The -8 means to use maximum compression.

For me, the bit-rate went down to 2.2 mbps either way.

It beats using a raw format, because using the latter would have meant, nothing would have detected my silent stereo channel, and the file would have been twice as large.

Dirk