## How to route a USB MIDI Keyboard to a JACK-MIDI Input, under Debian.

One of the possessions which I have is a USB MIDI Keyboard, which I’d like to be able to play, so that my computer’s software synthesizers actually generate the sound…

I know that this can be done because I’ve done it before. But in the past, when I set this up, I was either using an ‘ALSA’ MIDI input, belonging to an ‘ALSA’ or ‘PulseAudio’ application such as “Linux Multimedia Studio”, or I was using ‘QSynth’, which is a graphical front-end to ‘fluidsynth’, but in such a way that QSynth was listening for ALSA MIDI, and outputting JACK audio. This is actually a very common occurrence. I can switch between using the ‘PulseAudio’ and using the ‘JACK’ sound daemon, through a carefully set-up configuration of ‘QJackCtl’, which suspends PulseAudio when I activate JACK, and which also resumes PulseAudio, when I shut down JACK again.

But there is a basic obstacle, as soon as I want to play my MIDI Keyboard through ‘Ardour’. Ardour v6 can be run with the PulseAudio sound system, but only for playback, or, Ardour can be run with its JACK sound back-end, after JACK has been launched. Ardour cannot be run with its ALSA back-end, when PulseAudio is running.

The default behaviour of the Debian kernel modules, when I plug in a USB MIDI Keyboard, is, to make that MIDI connection visible within my system as an ALSA MIDI source, even though some applications, such as Ardour, will insist on only taking input from JACK MIDI sources, when in fact running in JACK mode. And so, this problem needed to be solved this morning…

The solution which I found was, to feed the Keyboard, which happens to be an “Oxygen 61″, to the ‘MIDI Through Port’ that’s visible in the ALSA Tab of QJackCtl’s Connections window. When MIDI sequences are fed there, they are also output from the System JACK MIDI sources, visible in the MIDI Tab of QJackCtl’s Connections window:

I should also note that, in many cases, the JACK clients can ask the JACK sound daemon to be connected to various inputs and outputs from within, without absolutely requiring that the QJackCtl Connections window be used. This explains why the audio output of Ardour was already routed properly to my PC’s speakers. But I found that I could only keep track of the MIDI connection, through QJackCtl’s Connections window. As the screen-shots above show, the second step is, to feed one of the System Sources to the appropriate Ardour MIDI input, in the MIDI Tab of QjackCtl’s Connections window.

The result was, that the synthesizer which I have available as an Ardour plug-in, played beautifully, in response to my pressing keys on the actual MIDI Keyboard, and no longer just, when I clicked on the graphical keyboard within the Ardour application window:

This on-screen keyboard can be made visible, by double-Alt-Clicking on the icon of the instrument, with Ardour in its Mixer view, and then expanding the resulting windows’ MIDI Keyboard fly-out. Yet, the on-screen keyboard was only useful for setup and testing purposes.

(Updated 12/07/2020, 17h20… )

## 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.

## Testing of USB Sound Device Complete.

According to my previous posting, I needed to do a more thorough test of the USB Sound Card I have bought, which is a “Focusrite Scarlett 2i2“.

In particular, I needed to address the discrepancy according to which, the Linux JACK daemon reports capture at 32 bits, while the specifications of the sound card state a 24 bit sample format.

Also, I needed to be sure whether it would run as well at 96 kHz, as it already did at 48 kHz.

According to my more complete test, the 32-bit sample-format which ‘QJackCtl‘ shows me, which can be viewed in its Messages box, state the ALSA parameters and not the JACK internals. Therefore, JACK has after all chosen to capture and/or play back audio at a physical 32 bits, at the 96 kHz sample-rate. This is not, after all, a statement of the JACK internal behavior.

Since I am using Linux, and since the manufacturer chose to rate this capture device as only being capable of 24-bit capture, I must assume that for hardware reasons the device uses 32-bit registers, but that only the first, most-significant 24 of those bits are accurate. Therefore, when I open ‘QTractor‘ – the Digital Audio Workstation / Tracker application, it is best to truncate its capture format to 24 bits as well, which is most probably what the Windows or Mac drivers for this device do.

Aside from that, using QTractor next, to capture a 96 kHz, 24-bit, stereo FLAC file was easy and uneventful. Further, the stability of my software suggests that I can play with the GUIs as much as I need to, to figure them out, and I will not screw anything up.

After I closed JACK, I next imported this FLAC file, that plays for 14 seconds, into “Audacity“, which has been set up to use the default sound settings (‘PulseAudio‘), and which performs an on-demand re-sampling of the FLAC file.

The on-demand FLAC playback is not filtered well by Audacity, but since it is running at 96 kHz, compared with the 44.1 kHz that the internal sound of the laptop runs at, this observation is not surprising.

And then the captured sound clip simply contains, what I spoke into my microphone.

Dirk

## USB Sound Card

One of the recent developments in Computing is, that the actual PCs and laptops have relatively poor sound-chip-sets inside, but that we can add an external sound card via USB. I refer to these as ‘USB Sound Cards’, but think that most people just refer to them as ‘USB Sound Devices’. An actual sound card, used to refer to a PCIe interface card, which we could physically insert into our PC bus, inside the case.

When people buy a USB microphone, because the USB connection is digital, they are in fact buying the Analog / Digital converter inside that microphone, which also makes it the logical equivalent to a sound card. And the fact that it would be a USB mike, does not imply worse quality than an external sound card. To the contrary, users can expect their USB mikes to outperform the internal sound on their devices, which is the whole point in buying them.

I have embarked on yet another project, which is to buy an external sound card that is physically separated from any actual mike or sound source, and to buy a quality mike as well. Hence, I have received my USB sound device already, that has 2 output channels and 2 input channels.

Mine is a “Focusrite Scarlett 2i2” USB Sound Device, even though I usually try not to make endorsements or indictments of commercial products. It is stated to be capable of sampling at 48 and 96 kHz, and stated to be capable of 24-bit precision. It requires a USB 2 connection.

Because sound is taken very seriously with such devices, its only available inputs are a combined XLR / TRS jack each (not a 3.5mm mini-cable). This means that I am still waiting for my XLR-jack microphone to arrive, without which I cannot test the Focusrite. ( :1 )

A plausible question which some readers might ask would be, Why did Dirk not just buy a USB mike? And my answer would be, Because what I pictured wanting was closer to a USB Sound Card, hence an Analog / Digital converter, that can accept a variety of input devices.

But this would also be the context, in which it might make sense to switch my laptop ‘Klystron’ into JACK sound-mode, which supports real-time 48 kHz at 24 bits, and which also supports 96 kHz…

After all, not long ago I was pondering what the settings should be, with which JACK will start, in terms of sample-rate etc..

A key point of this project is again, to test whether the device will work properly under Linux. ( :2 )