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…

dsc_0001 email

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…

Screenshot_20201206_091955

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:

Screenshot_20201206_092022

Screenshot_20201206_092039

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:

Screenshot_20201206_092206

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.

Tada!

 

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

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

Getting the integrated equalizer to work, from Debian Jessie, KDE 4.

I happen to have an older laptop, which I name ‘Klystron’, that is running Debian 8 / Jessie, with KDE 4 as its desktop manager. Don’t ask me why, but I tend to leave older builds of Linux running on some of my computers, just because they seem to be running without any deficiencies.

That laptop has lousy speakers. I decided a few days ago, that it would benefit, if I could get the 14-band graphical equalizer to work, that is generally available on Linux computers which, like that laptop, use the ‘PulseAudio’ sound server. However, on this old version of Linux, achieving that was a bit harder than it’s supposed to be. Yet, because I succeeded, I felt that I should share with the community, what the steps were, needed to succeed.

First of all, this is what the equalizer looks like, which I can now open on that laptop:

Equalizer_1

And it works!

 

In order to get this sort of equalizer working with PulseAudio, eventually, the following two modules need to be loaded:

module-equalizer-sink

module-dbus-protocol

And, if I gave the command ‘load-module…’ naively from the command-line, as user, because under my builds of Linux, PulseAudio runs in user mode, both these modules seem to load fine, without my having to install any additional packages.

On more recent builds of Linux, one needs to install the package ‘pulseaudio-equalizer’ to obtain this feature, or some similarly-named package. But, because these two modules just loaded fine under Debian / Jessie, I guess the functionality once came integrated with PulseAudio.

But I soon started to run in to trouble with these modules, and discovered why, then, the equalizer function was not set up to run out-of-the-box…

(Updated 6/26/2020, 10h30… )

Continue reading Getting the integrated equalizer to work, from Debian Jessie, KDE 4.

Getting Pulseaudio to schedule real-time threads under Debian / Stretch and beyond.

On the computer which I name ‘Phosphene’, I have Debian 9 / Stretch installed, and, going the popular route, the Debian maintainers have decided that ‘Pulseaudio’ should be the main sound server, while in certain cases, it can be made to coexist with the ‘Jack’ / ‘Jack v2′ daemon, the latter for more demanding needs. In my case, starting Jack suspends Pulse.

In addition, Debian systems I’m familiar with run ‘pulseaudio’ as user, and not as root.

But, the way my Pulse daemon is configured, includes a ‘loopback’ module, that sends audio that has been input and sampled from the analog input of my (“Creative X-Fi”) sound card, back to its analog output, so that I can listen to an old-fashioned-but-modern radio receiver, over my speakers, without having to connect anything special to do so.

The problem that I was experiencing was, buffer underruns, and sound drop-outs, due to the way this default sound server was operating the sound card. And, surely enough, it had something to do with a by-now famous issue, of allowing Pulse to schedule certain threads to run with real-time priority. This can be enabled in the config file ‘/etc/pulse/daemon.conf‘, but fails to become actual when just enabled so.

Trying to find an answer to why this attempt was failing, sent me on a trip to many Web-sites and BB-postings, most of which had as disadvantage, the fact that with Pulse, there is an old way and a new way to accomplish this, and the fact that most of the BB-postings assumed the old way, being dated to the year 2016 and earlier.

Rest assured, under Debian 9 / Stretch, authorizing Pulse to schedule some threads with RT priority, is managed according to ‘the new way’. Just to recap how ‘the old way’ worked:

The file ‘/usr/bin/pulseaudio‘ needed to be set with ‘SETUID root’, and when run this way, if the sound server detected that the real user (not the effective user) belonged to the group ‘pulse-rt‘, would schedule the threads it needed to run with RT, and would then drop privileges, so that according to the process-monitor ‘top’, it would never even give a hint that anything had in fact been scheduled with RT.

This is how ‘the new way’ is supposed to work:

If the user needs for Pulse specifically to run with RT, he must actually install the package ‘rtkit‘, which runs as a system user, and which sets certain threads to have RT priority in a curated way, that’s meant to be ‘safer’, than it still is for any one user to belong to a group, that simply allows him or her to run arbitrary processes with RT. In fact, ‘the old way’ was also meant as a similar safeguard.

I had installed the specified package, rebooted my system – with Pulse given its new startup parameters, and found alas, that the file ‘/var/log/syslog‘, which was benefiting from an elevated logging level set by me, revealed numerous messages that I did not understand.

Trying to figure out what was happening resulted in more than one day’s frustration, and then finally, to some peace of mind…

(Updated 4/16/2020, 13h15 … )

Continue reading Getting Pulseaudio to schedule real-time threads under Debian / Stretch and beyond.

PulseAudio Restart Bug – Solved

I enjoy my Linux computers, and one reason is the fact that many technical issues can be resolved, without having to reboot endlessly. However, in my past usage, there has been an irritating exception to this pattern. It’s common under Linux, that we can simply restart the PulseAudio Server from the command-line, using one out of several methods, and that the subject should be done with. But alas, every time I have ever restarted PulseAudio in this way, or, if the server restarted on its own, afterwards, when looking up the Plasma 5 -generated status display (which is actually referred to as “Phonon”), I’d be missing a Devices List, like so:

Screenshot_20191026_152751

This type of display can be interpreted to mean several things, such as, that the PulseAudio server did restart, but that perhaps, it simply failed to connect to the inter-process, session-unique, message-bus. Therefore, in the past, whenever I had such a display, I eventually did what I thought I had to do, which was, to log out and back in again, or, to reboot. On my system, PulseAudio is configured such, that it runs as one user-name, and not as root.

In fact, a peculiar side effect of this bug was, that the list of available output devices was still being displayed, within ‘pavucontrol‘.

But this ordeal has now become even more inconvenient than it ever was because on the computer which I name ‘Phosphene’, the need may recur more frequently, ‘just to restart the PulseAudio server’.

However, I have finally found the true cause for this malfunction, which was, that when PulseAudio is restarted from within an existing session, it simply fails to load one module, which is also the module that it needs, in order to be able to list the available devices:

 


module-device-manager

 

In fact, there exists a script in ‘/usr/bin‘, that loads a series of X11-related modules.

Therefore, after a restart of this service, I can simply give the following command now:

 


/usr/bin/start-pulseaudio-x11

 

And Eureka! I can now obtain a list of available devices, without ever having to log out and back in, or, without ever having to reboot:

Screenshot_20191026_152853

In fact, I have created a shell-script, which I can click on as user, and which carries out this task, safely.


 

I’ve also discovered that the ‘ProjectM’ music visualization application still works, and detects the beat of the playing music as before. What this means is that theoretically, after ‘ProjectM’ was installed, instead of rebooting, I could have just restarted the PulseAudio server as described here, to get that working.


 

( Edited 2019/10/29, 23h35 … )

I know that there exists an unrelated problem, that just happens to give the same appearance within ‘Phonon’, but that cannot be resolved in this way…

Continue reading PulseAudio Restart Bug – Solved