software

XFCE and Wayland

jeremy, , , Leave a comment

After having installed Raspberry Pi OS Trixie on a Pi 500+ I wondered if XFCE would run with the default Wayland setup. I’m going to use the 500+ as a desktop solution so it would be nice if it would run my go-to desktop manager without having to switch to X11. Turns out Trixie comes with XFCE 4.20 that has partial Wayland support. So installed it and configured it to run as the default desktop environment. This blog post describes the steps I had to go through to get XFCE running with Wayland.

LightDM

The default login manager of the Raspberry Pi OS is LightDM so in order to be able to log into an XFCE session some changes need to be made there. By installing XFCE a Wayland session desktop file gets installed too and by referencing this file in the LightDM configuration you can have LightDM starting up an XFCE session after a successful login. The involved entries are user-session and autologin-session under the [Seat:*] section. These default to rpd-labwc. Change the values of these entries to xfce-wayland and after having restarted LightDM you should log into an XFCE session. So your /etc/lightdm/lightdm.conf file should have the following entries:

[Seat:*]
...
user-session=xfce-wayland
autologin-session=xfce-wayland
...

Restarting LightDM can be done with sudo systemctl restart lightdm. Bear in mind this will log you out immediately!

XFCE

Within XFCE you can now customise the environment to your liking. I like the Greybird theme so I installed that and set it as the Style in the Appearance app. For the icons I prefer the elementary theme so after having installed that theme I selected it under the Icons tab. For the rest I’m OK with the defaults. After that I configured my panels. Setting the wallpaper and cursor theme with the XFCE tools doesn’t work though so I had to resort to setting those using the swaybg utility and the labwc window manager.

labwc

To set the wallpaper/background I installed the swaybg package and created the file wallpaper.desktop in ~/.config/autostart/ with the following content:

[Desktop Entry]
Type=Application
Version=1.0
Name=Set Wallpaper
Comment=Set Wallpaper
Exec=swaybg -i /usr/share/rpd-wallpaper/RPiSystem_dark.png -m fill
Terminal=false

You can change /usr/share/rpd-wallpaper/RPiSystem_dark.png to the path of he wallpaper of your choice. This will get picked up on your next login. Next up, the cursor theme. I prefer the DMZ-White theme and you can set this using labwc. labwc looks into ~/.config/xfce4/labwc/ for its configuration after having installed XFCE so I modified the environment file in that directory to look like this:

# Mouse settings
XCURSOR_THEME=DMZ-White

I also added a section to disable Caps Lock and map the right Alt key to the Compose key:

# Keyboard settings
XKB_DEFAULT_LAYOUT=
XKB_DEFAULT_OPTIONS=compose:ralt,ctrl:nocaps

I did some more personal customisation in ~/.config/xfce4/labwc/rc.xml, like changing and adding some key bindings and changing some theme settings. Having worked with Openbox for years (https://autostatic.com/tag/openbox/) this felt very familiar.

One thing was still missing and that was the network icon in my top panel. So I installed the network-manager-applet package and added the file nm-applet.desktop to the ~/.config/autostart/ directory with the following content:

[Desktop Entry]
Type=Application
Version=1.0
Name=nm-applet
Comment=Start NetworkManager taskbar applet
Exec=/usr/bin/nm-applet
Terminal=false

Loose ends

There must be a way to set the wallpaper right after login. Now it takes over 5 seconds before swaybg sets the wallpaper. Also intelligently hiding an XFCE panel only seems to work with maximised windows. So I’ve set “Automatically hide the panel” to “Always” for the bottom panel. xfce4-screenshooter can only take screenshots of the whole desktop, not of single windows. Another thing is the Raspberry Pi Control Center (rpcc), once I ran that it set some defaults, breaking some changes I had made. And disconnecting HDMI crashes XFCE.

References

I used to following sources to gather information:

XFCE and Wayland

Linux audio performance improvements

jeremy, , , , , , 2 Comments

This is a recap in blog form of the following Mastodon toot: https://mastodon.autostatic.net/@jeremy/115632831793380239

The biggest performance improvements when it comes to Linux audio you can do are in my experience:

  • Setting the CPU scaling governor to performance.
  • Disabling SMT (Simultaneous MultiThreading).
  • Allow your DAW to set CPU DMA latency. For instance Ardour and Reaper can do this.

The Ardour manual provides some great background information on these matters. CPU scaling governor and SMT are explained here: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/. CPU DMA latency is explained here: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/

All other recommendations that for instance rtcqs or Millisecond give are for those that really need stable, ultra low latency. So buffer sizes below 64 samples that result in round-trip latencies below 10 milliseconds. This is the area where threaded IRQs or disabling Spectre/Meltdown mitigations might contribute to getting rid of that stray xrun.

Regarding threaded IRQs, enabling those by itself doesn’t change anything. You will need to configure those threaded IRQs after you’ve enabled them. Tools that can do this are rtcirqus or rtirq. You could also do this manually by using the chrt command on the threaded IRQ process.

Modern systems use MSI(-X) interrupts though (Message Signaled Interrupts) so shared IRQs should be something of the past. On those systems there’s very little gain in prioritising threaded IRQs.

The main difference between rtcirqus and rtirq is that rtcirqus allows you to set the real-time priority of a thread based on ALSA card names. rtirq works differently, it sets the real-time priority based on kernel module names. So with rtcirqus you can be sure the desired audio interface gets the desired real-time prio, with rtirq you’re prioritising all the devices that make use of a specific kernel module (xhci_hcd, snd_hda_intel).

rtirq does allow for some finer grained control regarding USB2 ports and onboard audio devices that use the snd_hda_intel driver. The USB2 ehci_hcd driver and the snd_hda_intel driver add the bus name and card index number respectively to the IRQ thread process name so you can use that designation in the rtirq configuration file. In case of USB2 you’re still prioritising the IRQ of the whole USB bus though but then rtcirqus does the same.

Linux audio performance improvements

Now what does rtcirqus actually do?

jeremy, , , , , , Leave a comment

To answer that question let’s assume the following:

  • You want to do real-time audio, for instance you would like to do an overdub in a song project by using a MIDI keyboard and a soft synth.
  • You’re using a USB audio interface.
  • You’re experiencing xruns when using lower buffer sizes (64 or even lower) that result in crackling audio.

Basically all components of a desktop computer or a laptop have an IRQ. Let’s say IRQs are some sort of communication lines between the brains of your computer (the CPU) and those components. All these communication lines are more or less the same as in, none of these communication lines has priority over the other. But if you suffer from bad audio quality caused by xruns then giving the communication line that is connected to your USB device more priority than the rest could alleviate the audio issues.

This is where rtcirqus could be helpful. What rtcirqus does is detecting your USB audio interface when it gets connected, then it figures out what the IRQ of the USB bus is that your audio interface is connected to and raises the priority of the IRQ attached to that USB bus. In other words, rtcirqus gives the communication line between the USB bus that your audio interface is connected to and the CPU of your computer a higher priority. This higher priority translates into other communication lines being throttled and giving the communication line of our USB audio interface more room to transfer and receive its audio data.

rtcirqus needs to be able to prioritize that communication line though and this is where the threadirqs kernel option is for, it creates so-called threads of all available IRQs on a computer. Threads are more or less like processes running on your computer, with threadirqs enabled you can list them as such with a command like ps -eLo cmd | grep '^[irq'. So make sure this kernel option has been added to the kernel command line. In case you’re using a real-time kernel this isn’t needed as a real-time kernel uses threaded IRQs by default.

So if you find yourself in such a situation, head over to https://codeberg.org/autostatic/rtcirqus and give rtcirqus a try, maybe it helps you achieving lower latencies with your USB audio interface while retaining a clean audio output signal.

Now what does rtcirqus actually do?

Using Vim with ALE for Python linting and autocompletion

jeremy, , , , , , , Leave a comment

At work we use VS Code but if possible I would prefer not to use that on my work station at home. Since I’ve been apt purging nano for ages I started looking for a way to do this with Vim. In the end it turned out to be quite simple on my Debian Bookworm install.

Prerequisites

You will need the following packages:

  • vim
  • flake8
  • python3-pylsp
  • vim-ale

Install them with sudo apt install vim flake8 python3-pylsp vim-ale.

Configuration

Add the following lines to your .vimrc and you should be good to go!

syntax on

packadd! ale
let g:ale_completion_enabled = 1
let g:ale_linters = {'python': ['pylsp']}

On Ubuntu the situation is a bit different, the linter to add for autocompletion is called pyls but the executable is called pylsp. So to have ALE load the correct executable some extra configuration is needed.

syntax on

packadd! ale
let g:ale_completion_enabled = 1
let g:ale_linters = {'python': ['pyls']}
let g:ale_python_pyls_executable = 'pylsp'
Using Vim with ALE for Python linting and autocompletion

Running your own Mastodon instance with Docker

jeremy, , , , , Leave a comment

This is on a Ubuntu 22.04 server. Install the necessary Docker packages first.

sudo apt install docker-compose-v2

Add a mastodon user with UID and GID 991.

sudo groupadd -g 991 mastodon
sudo useradd -u 991 -g 991 -m -d /srv/mastodon -s /bin/false mastodon

Now cd to /srv/mastodon, clone the Mastodon repository and check out the current version.

git clone https://github.com/mastodon/mastodon.git .
git checkout v4.2.8

Build the Mastodon image and set correct ownership of the public directory.

docker compose build
sudo chown -R mastodon: /srv/mastodon/public

Now run the Mastodon setup step.

copy .env.production.sample .env.production
docker compose run --rm web rake mastodon:setup

Fill in the necessary details but leave the Redis password blank. Make sure the (sub)domain you want to use has a proper DNS record. The setup outputs a set of variables, copy and paste those into .env.production after having deleted the old content. Since this file contains credentials you could chmod 400 it so only the user firing up the Docker setup has read access.

Start the Mastodon stack.

docker compose up -d

And verify all containers come up healthy. Now you can put your Mastodon instance behind a reverse proxy. I’m running Apache myself and the configuration below works for me. Bear in mind it relies on a working Let’s Encrypt certificate, you will have to create one yourself.

<VirtualHost *:80>
        ServerName mastodon.yoursite.net
        ServerAdmin yourname@yoursite.net
        AssignUserID mastodon mastodon # Only applicable when using MPM-ITK

        DocumentRoot /srv/mastodon

        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>

        Redirect permanent / https://mastodon.yoursite.net/

        ErrorLog ${APACHE_LOG_DIR}/mastodon.yoursite.net.error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/mastodon.yoursite.net.access.log combined

</VirtualHost>


<VirtualHost *:443>
        ServerName mastodon.yoursite.net
        ServerAdmin yourname@yoursite.net
        AssignUserID mastodon mastodon # Only applicable when using MPM-ITK

        ProxyPreserveHost On
        ProxyPass /api/v1/streaming http://localhost:4000/
        ProxyPass / http://localhost:3000/
        ProxyPassReverse / http://localhost:3000/

        RequestHeader set X-Forwarded-Proto "https"

        SSLEngine on
        SSLProxyEngine on
        SSLCertificateFile      /etc/letsencrypt/live/mastodon.yoursite.net/cert.pem
        SSLCertificateKeyFile   /etc/letsencrypt/live/mastodon.yoursite.net/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/mastodon.yoursite.net/chain.pem

        # intermediate configuration, tweak to your needs
        SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
        SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
        SSLHonorCipherOrder     off
        SSLCompression    off

        # HSTS (mod_headers is required) (15768000 seconds = 6 months)
        Header always set Strict-Transport-Security "max-age=15768000"

        ErrorLog ${APACHE_LOG_DIR}/mastodon.yoursite.net.error.log
        CustomLog ${APACHE_LOG_DIR}/mastodon.yoursite.net.access.log combined
</VirtualHost>

Reload Apache and visit your Mastodon instance with the admin account you created. The result of these steps can be found here: https://mastodon.autostatic.net

References:

Running your own Mastodon instance with Docker

rtcqs v0.6.1 released

jeremy, , , , , , 2 Comments

A new version of rtcqs, a Linux audio performance analyzer, is now available. Most notable changes include:

  • Fixed inconsistent use of single and double quotes
  • Replaced audio group check with a group agnostic check (fixes #4)
  • Governor check can now deal with systems that have SMT disabled
  • Tickless check now deals with all CONFIG_NO_HZ* variants and with nohz being set on the kernel command line (fixes #8)
  • File systems check has been expanded
  • IRQ check now loops through /sys/kernel/irq instead of parsing /proc/interrupts
  • rtprio check now checks if a SCHED_FIFO priority can be set instead of a SCHED_RR priority
  • Improved preempt RT check, check if “preempt=full” is part of the kernel command line (fixes #7)
  • Refactoring, created separate classes for main app, resources and GUI
  • Moved all packaging directives into pyprojects.toml

While working on this release I found out PySimpleGUI is not open source anymore so rtcqs’ GUI has become a bit of a moving target. I’m looking at alternatives like pygubu or even popsicle but that will be something for in the long run. In the short run there are more improvements in the pipeline. The swappiness check needs some attention and same goes for the IRQ check. I’ve been working on a different project to automate prioritizing IRQs and I’m planning to to reuse some parts of that project for the IRQ check in rtcqs. The idea is to have rtcqs not only list the status of all audio related IRQs but also any audio devices attached to those IRQs.

rtcqs is available on Codeberg, PyPI and is also included in the AUR.

rtcqs v0.6.1 released

Balancing act

jeremy, , , , , , , , , , Leave a comment

At the moment everything seems a bit like a balancing act. First on a physical level, as I’m currently recovering from surgery one of the things I have to learn again is to find my balance, literally. While recovering I can’t do very much hobby stuff in the analogue domain so I swayed a bit to the digital domain again.

About 6 years ago I bought a Mixbus 32C license but found myself using Ardour more and more. During the pandemic I took a subscription and from then on I basically started using Ardour exclusively. Still remember the first time I opened up Ardour back in the 00’s, to me it was intimidating, daunting, what did all those buttons and sliders do? But like with more things in life, sometimes you just fathom the seeming complexity of something, call it an eye opener, and then you’re like, why didn’t I start using Ardour right from the beginning?

Now Ardour is my DAW of choice. It’s running on Debian 12 with a Liquorix kernel on my old, trusted BTO and I’ve never had such a stable setup before. Yes, Debian, after 14 years of Ubuntu that has become a balancing act too. The more applications are moved into Snap the more it alienates me from the OS. While I understand the concept of self-contained applications, it’s part of my job, I don’t think this concept has a real purpose on a desktop OS. It adds another layer of complexity and makes communication between applications harder. Whole different story for another time.

Ardour 8.0 has just been released and I can wholeheartedly recommend it. Installing and setting it up is a breeze and even on my old BTO it runs like a charm. The only restriction is that I can’t use too many Dragonfly Reverb plugins within a project but once I give in to my GAS to get a Framework notebook that will be resolved too.

Balancing act

rtcqs v0.4.2 released

jeremy, , , , , Leave a comment

This release comes with a new Power Management check which checks if the audio group has read/write permissions on /dev/cpu_dma_latency. If your user is a member of the audio group and permissions are set for this group then DAW’s like Ardour and Reaper can open this file as your user, keep it open and control power management this way. This allows a user to prevent CPU sleep states for example so your CPUs are always on and instantly available which could lower the chance running into xruns.

Ardour CPU DMA latency setting Under Edit – Preferences – Performance

This release also introduces a new basic and simple tkinter-based GUI. The Qt GUI does look fancy but to use it it also needs a fancy amount of dependencies. When building binaries with PyInstaller the result of the Qt GUI is a whopping 130MB package while the tkinter version stays below 12MB.

rtcqs tkinter GUI

Future plans are to get rid of some checks:

  • Max user watches as it’s not related to the overall performance of your system
  • System timer as it’s not relevant anymore, rtcqs already checks for the more relevant stuff (high res timers and tickless kernel)
  • Background processes as it’s merely a placeholder which checks for two processes that don’t exist anymore on modern systems

I’m having my doubts about swappiness too as it’s not really applicable anymore for modern machines. But I’m curious if it still applies for smaller systems like RPi’s for example. I’d like to add a filesystem mount option check, for Ext it would check if the filesystem is mounted at least with the relatime option or even noatime for example. And maybe a disk scheduler check but I’m not conviced yet that it really makes a difference.

The new release and binary packages of rtcqs and rtcqs_simple_gui can be found on the Codeberg repo: https://codeberg.org/rtcqs/rtcqs/releases/tag/v0.4.2

rtcqs v0.4.2 released