For Linux remote hosts, XDMPC (using Xming or some other X-server) is better than Windows Remote Desktop Connection, via VNC or other such protocols
I found two better ways to control Cabbage from my Windows machine. The first involves the built-in (to Windows 7) Start > Programs > Accessories > Remote Desktop Connection using the Xorg protocol (not to be confused with the XDMCP protocol), which I think requires the xrdp and/or xorgxrdp packages to be installed. This works OK, but there is no connection with the Windows clipboard, and the entire desktop size (actually there are four workspaces, any one of which can be seen in the desktop) is fixed as the size of one of my monitors: 1920 x 1200. The window can be made smaller, but this only shows part of the desktop - the desktop itself is not resized.
The second, which I think is better, uses Xming or in principle any other suitable X-server on the Windows machine to directly access the desktop of the Linux machine using the XDMPC protocol. This is not related to SSH, and is suitable for a LAN. I had numerous frustrations getting this going, though in principle it is simple. I couldn't understand why it worked on some Linux machines and not on others, but I had been mucking around with various packages and settings. So I started afresh and got it working without any fuss.
With Xming and XDMPC, the size of the desktop (and so the four workspaces, which are accessible via the miniatures at the top right) instantly adapts to the Xming window size on the Windows machine. Cabbage works fine with this arrangement, in contrast to the problems I encountered as mentioned above.
The individual application windows are all within the desktop rectangle, however big this is, whereas with ordinary SSH X forwarding, as I was attempting previously, each window produced by Cabbage, including the GUI windows for each .csd file, was a separate Xming window on my Windows machine which I could move anywhere and individually minimise. XDMPC's arrangement of all the windows being within the one desktop window is something of a limitation. However, I can make the desktop as big as I like - including spanning four 1920 x 1200 monitors. This expansion, unfortunately, creates a high risk of crashing Xming. I am still figuring out how to do it - I think it may be best to do moderate expansions quickly, rather than dragging the edge of the window slowly before Xming and Xfce catch up with the size the window was 50ms earlier. Perhaps it is better to change the size when the desktop is relatively empty.
An advantage of all the Cabbage windows being in a single resizable and minimisable desktop window is that if I have multiple Linux machines, each running an instance of Cabbage (I assume that only one can run), then I won't be so easily confused by having the various windows of four Cabbage installations all over my Windows desktop.
With the cursor inside a desktop window such as this, Alt-Tab is captured by Xming and sent to Xfce, which steps through the available applications. This is good, since otherwise there would be no quick way of stepping through them, and is probably better than having these remote programs all mixed up with Windows programs. The single desktop window appears as a single item in the Windows alt-tab list. (I use VistaSwitcher to provide 4 rows of 12 icons for Alt-Tab to run through.)
Fresh install of Debian 9.4 with Xming & XDMPC setup
Here is how I did a fresh install of Debian 9.4, set up this XDMPC arrangement with Xming, then then built Csound, Juce and Cabbage. This was on a dual X5670 Xeon machine, but I had previously done something similar on an old 64 bit Core Duo laptop. On the laptop I used a live/install ISO but here, for the Xeon machine, I used a net-install ISO, since it had trouble mounting the live/install one. (In this IBM x3550, with the live/install ISP the "Detect and mount CD-ROM" step failed with "Installation step failed", which did not occur with the net-install ISO.) This explanation is rather long, but it might help someone get Cabbage running nicely, since it specifies everything from the start of the Debian installation. There are other Linux distributions perhaps better suited to audio, but I need these machines for other purposes too.
I used a net-install ISO file with non-free software and "extra firmware", since these IBM x3550 Xeon machines have an Ethernet chip which requires a non-open-source driver. These come from http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ . The particular ISO file is /9.4.0+nonfree/amd64/iso-cd/firmware-9.4.0-amd64-netinst.iso . I wrote this 340MB ISO to a USB stick using in32 Disk Imager 1.0 https://sourceforge.net/projects/win32diskimager/ . This creates a suitable file system for booting from USB. I chose "Advanced options > Expert installer" which is a graphic installer which enables me to set a fixed IP address easily. (Other installers use DHCP and then allow me to go back and set the fixed IP address.) I set up both root and robin accounts, rather than just robin as a sudoer. At "Software selection" I chose Debian desktop environment, Xfce, SSH server and Standard system utilities".
I can't yet log int via SSH as root, though I do this later since it is the only way I have found to run Synaptic via X forwarding via my Windows machine. ("sudo synaptic" works fine via XDMPC, but that is not yet set up.) I SSH to the machine as user robin, which is not a sudoer yet, so I su to root.
apt-get install mc
I log in separately as robin and run Midnight Commander (mc) once, set the configuration: Always, internal edit and safe delete, save the setup and exit. Then with mc as root I set the same options and edit /home/robin/.config/mc/ini to alter a line which specifies better colours than the default of blue and white, with the nearly indistinguishable yellow for highlighting:
As root, I add a line 25 in /etc/ssh/sshd_config : "PermitRootLogin yes" and restart the SSH server: "service sshd restart" . Now I can SSH to the machine as root. For both root and robin: "update-alternatives --config editor" and choose "2" for mcedit. As root:
apt-get install sudo
Due to the previous step this will run mcedit, rather than nano or the original vi editor (the inscrutable editor of seriously old-school uber-Unix-geekcom, which is not even mentioned nowadays in update-alternatives). I add a line after the root line: "robin ALL=(ALL) ALL". Now user robin is a sudoer and I can use sudo for all superuser commands. I update all the currently installed packages, but this produced no changes since I just installed the system:
sudo apt-get dist-upgrade
htop displays process information in real-time, with activity for each "CPU", which in this Xeon machine means a logical-processor - and there are two logical processors (Intel hyperthreading) per core. I won't document my NFS (linking Linux file systems) or SAMBA (Windows file access to Linux machines) setup. lm-sensors provides the "sensors" command which can report the temperature of individual cores of the two CPU chips.
sudo apt-get install htop samba nfs-common nfs-kernel-server lm-sensors cpufrequtils
Package cpufrequtils includes a program "cpufreq-info" which reports on the "governor" used by each of the logical processors in the system, though these are referred to as "CPUs" in its report, and as "cores" by Cabbage. The dual Xeon machines have two CPU chips, each with 6 cores (and their physical numbering is not contiguous). Each core has two register sets which it switches between as part of Intel's hyperthreading. Each such register set's operation of the core is presented to the operating system as (the best term I know) a "logical-processor", each of which can run a thread. But the core's activity is switched rapidly between these two threads, including especially when one thread has to wait for a few dozen clock cycles when it needs data which is not in the L0 cache (a "cache-miss").
For real-time work, we need to do 3 things which most people don't worry about. Firstly we need to (1) set the performance governer for the entire machine. (This is reported per logical-processor, but as far as I know the governor works per core - and we want to use the "performance" rather than the "ondemand" governor for all cores.) This means the cores are already running at their maximum clock frequency, so real-time code is not delayed by some microseconds or whatever in which the core speeds up to its maximum clocke rate when it becomes newly active with work. On this system, with the default-installed "ondemand" governor, the cores run at about half their maxium clock rate, and so at about 1.5GHz, when they are not being used very much. The easiest way to set this is by creating a file /etc/default/cpufrequtils and have it contain the following line:
This takes effect after a reboot, and the reasults can be seen by "current CPU frequency" lines in the output of cpufreq-info.
Secondly, we want to disable the second logical processor (or the first, either will do), to (2) disable hyperthreading. This way, each core only uses one register set and cannot switch to the other (the other logical-processor running some other thread) as soon as it hits a cache miss. The Ardour manual mentions disabling hyperthreading, but has no guidance on how to do it: http://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ I believe the statement there that this is becoming less common is incorrect. All but the weediest of modern Intel x86-64 CPUs use two-way hyperthreading per core. This can be turned off in the BIOS/UEFI, but I want it on for general computing and off for real time music work.
As far as I know there is no official standard for how the logical-processors are mapped to the "CPU" numbers within Linux. By scrutinising the output of cpufreq-info, by observations with htop (which can be set to number the "CPUs" from 0, rather than 1), and by other reading and experiments I determined that in order to shut down the second logical-processor of each of the 12 cores in these dual Xeon machines, it suffices to run a script, as root, with the following commands - hyperthreading-off.sh:
#echo 1 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu3/online
echo 1 > /sys/devices/system/cpu/cpu4/online
echo 1 > /sys/devices/system/cpu/cpu5/online
echo 0 > /sys/devices/system/cpu/cpu6/online
echo 0 > /sys/devices/system/cpu/cpu7/online
echo 0 > /sys/devices/system/cpu/cpu8/online
echo 0 > /sys/devices/system/cpu/cpu9/online
echo 0 > /sys/devices/system/cpu/cpu10/online
echo 0 > /sys/devices/system/cpu/cpu11/online
echo 1 > /sys/devices/system/cpu/cpu12/online
echo 1 > /sys/devices/system/cpu/cpu13/online
echo 1 > /sys/devices/system/cpu/cpu14/online
echo 1 > /sys/devices/system/cpu/cpu15/online
echo 1 > /sys/devices/system/cpu/cpu16/online
echo 1 > /sys/devices/system/cpu/cpu17/online
echo 0 > /sys/devices/system/cpu/cpu18/online
echo 0 > /sys/devices/system/cpu/cpu19/online
echo 0 > /sys/devices/system/cpu/cpu20/online
echo 0 > /sys/devices/system/cpu/cpu21/online
echo 0 > /sys/devices/system/cpu/cpu22/online
echo 0 > /sys/devices/system/cpu/cpu23/online
This has a line for each logical-cpu. The first one of each core is left in its 1 = enabled state. The second one is disabled by "0". Only the "0" lines are needed, but the others are for completeness. We are not allowed to mess with the online status of cpu1. (We might find ourselves in a "Stop . . Dave . . . " scenario if we did.) I have another script with all 1s to turn hyperthreading back on. Be sure to close and restart htop after running either such script. I put these scripts in my home directory and run them with sudo. With hyperthreading off, htop shows only 12 "CPUs", instead of the usual 24.
The third thing which needs to be set up for real-time work concerns (3) realtime scheduling, as described at: http://jackaudio.org/faq/linux_rt_config.html . I don't understand this in detail or know how to test its effectiveness. I think the Ardour installer does this, but I haven't yet installed Ardour. The steps I took were:
1 - As root, create and edit a file called /etc/security/limits.d/99-realtime.conf containing:
@realtime - rtprio 99
@realtime - memlock unlimited
2 - As user robin, create the "realtime" group and make this user a member of it:
sudo groupadd realtime
sudo usermod -a -G realtime robin
3 - Log out of whichever session this was an log in again. (For the purposes of running Cabbage without any menu etc. problems, I need the new login to be via a new Xterm session launched from Xfce's desktop (or from its Applications menu) I am remotely accessing via XDMCP and Xming. However, at this point I don't have XDMCP set up or Cabbage compiled.)
To enable XDMCP remote desktop access, in the Linux machine we need to tell the display manager to allow this. In this installation, this is lightdm. The display manager orchestrates the initial graphic login process in a way which enables the user to choose between multiple "desktop managers" (or by some other names). In this installation there is only one: Xfce. As root (sudo mc and then use F4 to edit the file) I edit /etc/lightdm/lightdm.conf such that:
Then I reboot or restart it:
sudo systemctl restart lightdm.service
This is all that is required. There are no packages to explicitly install. lightdm was already installed, and I guess that it relies on the libxdmcp6 package, which was also already installed, for this functionality. (I got into all sorts of bother when I was confused between XDMCP and various other remote desktop protocols, such as RDP, as used by the xorgxrpd and xrdp packages, neither of which are needed for XDMCP.)
It is possible to use other X-servers than Xming for XDMCP remote desktop. There is a command, below, by which I start Xming to do this for each particular Linux machine. First I will show the interactive way of testing XDMCP availability and how this leads to running an instance of Xming to access the Xfce desktop. I already have Xming installed in my Windows 7 machine so that it runs at startup. There is a shortcut in my Start > Programs > Startup directory which runs this command (which is the ordinary supplied command for running Xming as part of the version 184.108.40.206 donationware current release):
"C:\Program Files\Xming\Xming.exe" :0 -clipboard -multiwindow -nolisten inet6
This causes an instance of Xming to run continually, creating an icon in the system tray. It can run any number of SSH X forwarding sessions which originate in PuTTY. For the configuration of PuTTY, turn on "Enable X forwarding" in each host's profile's Connection > SSH > X11 section. (Don't enable this for hosts outside the LAN - bad things happened when I did this for hosts in other countries.) This normally-running instance of Xming uses "Display 0". Each of its sessions gets a separate window, which can be resized and made full screen (within a monitor). The command lines given below fire up an instance of Xming which connects to a particular host, by name or IP address, on the LAN and creates a single resizable window for XDMCP remote desktop. These instances need to be able to run at the same time as each other, including the normally running Xming instance, and all such instances need to have a different "Display" number. So for five such XDMCP commands (each in a separate shortcut in one of my Start menu directories (using the Classic Start Menu program, but you can put them on your desktop) I use "Display" numbers 1 through 5.
Back to the interative method. In Start > Programs > Xming there is a shortcut "Xlaunch" which runs Xlaunch.exe - which may later run Xming with a particular command string. I run Xlaunch, type in "9" or some such number not otherwise used for "Display number" and select the "One Window" option. The "Multiple windows" option can't be used for XDMCP. This is the mode just described for the continually running Xming instance. "Full screen" and "One window without titlebar" can be used fr XDMCP, but I choose not to. The Fullscreen mode covers the screen of the Windows monitor which has the task bar. It can't be made any smaller, and it is difficult to figure out how to minimise. The "One window without titlebar" has similar problems. The "One window" mode results in a window which can be resized, or made full screen (single monitor) like any ordinary Windows program, which is what I want. I click "Next". In the next step I select "Open session via XDMCP" and click "Next".
For the next step I leave the "Connect to host" option set, rather than "Search for hosts (broadcast)" and I leave the 'Use indirect connect" option unselected. In the XDMCP host chooser section I click the XPing button and wait for 15 seconds or so until it greys out and the Reset button is in black. Above will be a list of the names of hosts (Linux machines) on my LAN which are ready to accept XDMCP connections. This means they are accepting UDP packets on port 177 and responding in particular ways. Assuming more than one is listed, I select the name of the host I am setting up and click "Next", "Next" and "Finish". (At the last step I can save a configuration file. The configuration file can be double-clicked to launch Xming, but I choose to do it via shortcuts.) The newly started Xming instance can be found with Alt-Tab or by finding a second Xming icon in the System Tray, with a mouseover indicating the "Display" number just entered into Xlaunch. If all is well, this will be window which nearly fills the primary Windows monitor screen, but is not full-screen. It will show the blue Debian background with lightdm's login box for username and password.
Using this, (with a few seconds delay, and first time, the option for a default config, which I choose) I get my Xfce desktop for either root or robin. It can be moved, resized and made fullscreen. Cabbage works like a charm within this system. A command line for a shortcut to make this happen for a particular Linux machine, here specified by its IP address, with a particular initial size for the window, is:
"C:\Program Files\Xming\Xming.exe" :1 -screen 0 1920 1170 -keyhook -query 192.168.1.50 -clipboard -nowinkill
This appears in the primary monitor's screen. Specifying a width wider than this will not produce a wider initial window.
So setting up XDMCP with Xming is actually very easy. My difficulty in recent days was that I didn't clearly understand what it was and how it was unrelated to VNC and other remote desktop protocols. (I was confused by the "Xorg" option in MS Remote Desktop Connection, which I was able to get working with one, the other or both of the xordxrdp / xrdp packages. Whatever that is, MS Remote Desktop Connection does not work with the XDMCP arrangments just described.)
One more thing which I think is worth doing: From the Xfce desktop: Applications > Settings > Power Manager > Display: Turn off "Handle display power management" and set the Blank slider to the left for "Never". I think this is needed to prevent the remote XDMCP representation of the desktop being black, and not woken up by keyboard or mouse/trackball action on the Windows machine.
So now I have a basic Linux setup. I reboot it and check that XDMCP still works. I installed a bunch of packages for C, C++ etc. compilation:
sudo apt-get install build-essential
It doesn't matter to Cabbage or anything else where Csound is built. I compiled it from http://csound.com/download.html 6.11.0.tar.gz broadly according to https://github.com/csound/csound/blob/develop/BUILD.md#debian, which assumes getting the source with git . I untargzipped it into /audio/csound-cabbage-build/Csound-6.11.0/csound/ and the build directory was parallel to this: /audio/csound-cabbage-build/Csound-6.11.0/cs6make/ . This seemed to work fine:
Edit, as root, /etc/apt/sources.list and ensure that each line beginning with "deb" has another line below it that is identical except that "deb" is replaced with "deb-src" (which was the case). Then (cmake was already installed, but its installation is mentioned here for completeness):
sudo apt-get update
sudo apt-get build-dep csound
sudo apt-get install cmake
sudo make install
I can run "csound -h" and get a help message.
Building Projucer and Cabbage
I downloaded Cabbage 2.0.02 as a tarball rather than getting it from git. The link from http://cabbageaudio.com/download/ was to a zip file, but I looked in https://github.com/rorywalsh/cabbage/releases and chose the tarball (tar.gz) version of the source code. From messages above I understand that Rory usually has particular locations for building Cabbage and Juce and that they are normally in the same relative locations to each other. Here I have Juce (the audio-aware multi-OS framework) in its normal location in my home directory, but the Cabbage build somehere else, since I will want to compile several versions of it, including perhaps with my own tweaks. I untargzipped (Midnight Commander F2) the source into /audio/csound-cabbage-build/cabbage-2.0.02, hereafter referred to as "BB".
The readme files are in markdown format and are more easily read as plain text. See message 1 above about how I found it hard to get a good free Windows markdown reader. Also, note that the git rendering of the Linux instructions is actually less readable than the original readme.md text, since it shoves multiple, separate line, shell commands all into one paragraph. I couldn't find a git rendering of the actual 2.0.02 readme.md file for Linux, but the current version is at: https://github.com/rorywalsh/cabbage/tree/master/Builds/LinuxMakefile . In my source directories, it is at BB:/Builds/LinuxMakefile/readme.md .
readme.rd states, in part: "The VST SDK can be downloed from https://www.steinberg.net/en/company/developers.htm Make sure that the VST SDK resides in a folder called SDKs in your home directory, i.e, ~/SDKs". There are three SDKs at https://www.steinberg.net/en/company/developers.html , two of which have "VST" in their names. I chose the first one "VST 3.6.9 Audio Plug-Ins SDK". I unzipped it ("unzip") to /home/robin/SDKs/VST_SDK/ .
readme.sd also states: "You will also need to download the latest version of JUCE (master branch, 5.2)
- Build the Projucer". As I learned from the above, Cabbage needs precisely Juce 5.2.0, from October 2017. I got the tarball from https://github.com/WeAreROLI/JUCE/releases and placed its contents in /home/robin/JUCE, hereafter ~/JUCE .
My dependency packages for Cabbage, based on readme.md and builds in recent days involve not removing jackd2. This is after sudo apt-get update. Many of these packages were already installed:
sudo apt-get install libfreetype6-dev libx11-dev libxinerama-dev libxcursor-dev mesa-common-dev libasound2-dev freeglut3-dev libxcomposite-dev csound libcsound64-dev libcsnd-dev libsndfile1 libsndfile1-dev libjack-jackd2-0 libjack-jackd2-dev libxrandr-dev ttf-mscorefonts-installer software-properties-common
sudo add-apt-repository ppa:webkit-team/ppa
sudo apt-get update`
The last two steps generated some errors, as noted in message 6 above.
In order to build Cabbage, we need an executable Projucer, which functions both as a command line program for altering files and as an X program. (I think that when running from an SSH shell, it also needs to be able to display itself as an X program, even though I don't see it. Earlier, when I tried to build Cabbage via SSH when my Windows machine was not properly configured for X forwarding, so Projucer could not run as an X application via Xming, it actually did none of the work it was required to do, and the build failed with all sorts of errors due to it proceeding on the basis of the files from the tarball which Projucer was supposed to overwrite.)
I want to use Juce under the GPL so I need to build Projucer from source. I also need to build Projucer from source because there is no already compiled executable in the zip or tar.gz files in the Releases page as mentioned above. (There is such an executable in the very latest release's zip file from the juce.com downloads page.) The first step in doing this is to alter the file /home/robin/JUCE/extras/Projucer/JuceLibraryCode/AppConfig.h (https://github.com/WeAreROLI/JUCE/blob/5.2.0/extras/Projucer/JuceLibraryCode/AppConfig.h) so line 35 is: "#define JUCER_ENABLE_GPL_MODE 1".
Message 2 above describes how I came up with these dependencies.
sudo apt-get install freeglut3-dev g++ libasound2-dev libcurl4-openssl-dev libfreetype6-dev libjack-jackd2-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev libxrandr-dev mesa-common-dev webkit2gtk-4.0
make -j4 CONFIG=Release
The result was a 10MB executable ~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer .
Now to Cabbage . . . The program Projucer is used by the Cabbage build script several times. As far as I know, it writes a directory full of stuff at BB/JuceLibraryCode/ deleting what was initially there before writing files and directories. The Cabbage tarball contains files and directories in BB/JuceLibraryCode/ but as far as I know, these are overwritten in the build process.
The Cabbage build script for Linux is: BB/Builds/LinuxMakefile/buildCabbage. (I don't know how to point to this file for 2.0.02 on GitHub. Here is the current version: https://github.com/rorywalsh/cabbage/blob/master/Builds/LinuxMakefile/buildCabbage, which is already very different from the version I am working with.) I made a copy so I could easily compare it with the modified copy I am about to make. (I use Beyond Compare for such comparisons, and FileLocator Pro, AKA Agent Ransack, for searching for items in directories full of text files.)
There are 5 instances of using a relative path to specify the location of Projucer:
I changed these to an absolute path:
The first one doesn't matter, since it only runs if we use an argument "debug" after the Projucer command, which we don't , but I changed it anyway.
I did not attempt to fix a problem with line 14 which generates an error "./buildCabbage: line 14: [: ==: unary operator expected" if the script is run without any argument. This error can be ignored.
Next I made some changes to these 5 files, for reasons explained in the message 9 above, point 2:
The MIDIEffect one is not referred to in the build script, but I updated it anyway. In the MODULES section at the end, every line should end with "useGlobalPath="1"". Some of them already have such an item, but set to 0. So
<MODULE id="juce_core" showAllCode="1" useLocalCopy="1" useGlobalPath="0"/>
is changed to:
<MODULE id="juce_core" showAllCode="1" useLocalCopy="1" useGlobalPath="1"/>
In order to keep the last line of buildCabbage happy, it is also necessary to create a directory, if none existed:
Now, cd to the BB/Builds/LinuxMakefile/ directory, pray to the relevant deities and give the command:
This took a few minutes. The only compiler messages were warnings concerned deprecated declarations in CabbageToolbarFactory.cpp.
There was an error resulting from the last part of buildCabbage which normally (at least it worked for me with Csound 6.10.0) resulted in the creation of a little executable BB/Builds/LinuxMakefile/testCsoundFile. The problem "undefined reference to
csoundGetInputName" results from something NQR around line 911 in the 6.11.0 /include/csound.hpp which was not in the 6.10.0 version. Cabbage does not rely on this executable.
Apart from the a file ~/.local/share/applications/cabbage.desktop the results are all in /Builds/LinuxMakefile/CabbageBuild/ :
The first two are X applications. The next two are libraries for these. opcodes.txt is Csound's list of opcodes. There's no installation of executables or libraries. From an xterm I was running via the Xfce desktop. via XDMCP on my Windows machine, and from the CabbageBuild directory I gave the command:
and the program appeared and ran correctly. In the xterm session in which I gave this command, some errors appeared, including:
Xlib: extension "MIT-SHM" missing on display "localhost:12.0".
as was the case when I ran it from an SSH session and X forwarding (messages above). However, unlike those situation, now there is no trouble at all with the menus not operating, or with any other apparently faulty behavior or delays.
With hyperthreading turned off, and the new governor arrangement, when a .csd file is loaded, Cabbage reports correctly a clock speed of 3059MHz. (Actually, in general, clock speeds can vary between cores, and vary from one time to another - but will all be at the same speed with the new governor arrangement, unless perhaps the cores get too hot.) Cabbage also reports "18 cores". This should be "logical-processors" on a Xeon or i7. The number is incorrect. The active logical-processors can be found by scrutinising the output of cpufreq-info. This reports on "CPUs" 0 to 17, but those numbered 6 to 11 have no line such as: "CPUs which run at the same hardware frequency: 12". So this is a difficult way of seeing how many are active. htop shows the number of active logical-processors clearly, an numbers them 1 to 12 or 0 to 11. A script, here with its middle cut out to save space:
. . .
shows the active ones as "1":
I was able to run MultiReverb.csd at 48kHz with a UCA222 interface, but needed a very long buffer of 1920 samples to avoid glitches. This was true both before and after I did the above realtime scheduling steps, so perhaps I didn't get them right. I have not yet installed Ardour, and in previous tests in which I could run the UCA222 with much lower buffer sizes, I had already installed Ardour. Next I will try a PCI RME sound card and Ardour.