technology

Why I Won’t Be Attending or Speaking at Ubuntu Summit 25.10

Ubuntu Summit’s decision to go exclusively online, with the exception of those speaking at the Summit in London, UK, is anti-collaborative and turns its back on the very people who make Ubuntu what it is: its community of volunteers and developers. Ubuntu Summit was created from the dust of the Ubuntu Developer Summit in 2022 to recognize the community. It no longer serves that purpose.

As many know, I have been the lead of Ubuntu Studio for more than 7 years. I’m the longest-tenured Ubuntu Studio lead. I owe much of the foundation that was built to my predecessors: Luke Yelavich (founder), Scott Lavender, Kaj Ailomaa, and Set Halstrom. It is a true labor of love for me, and is the foundation for much of what I do.

I have worked myself through the ranks of Ubuntu, becoming a small-time packager for a small set of Ubuntu packages, then the Ubuntu Studio packageset, moving up to MOTU (Master of the Universe). I also served on the Ubuntu Community Council and am a current Discourse moderator.

Community and the love of people is a huge motivation for me. Granted, for those first four years, I hadn’t ever met the people I was collaborating with to make Ubuntu Studio what it is.

Then in August 2022, I was invited to attend the first ever Ubuntu Summit 2022 in Prague, Czechia. Having never travelled abroad before and never having even been off the continent of North America, itself a challenge as getting a U.S. passport is neither cheap nor easy, I was reluctant at first. Then I managed to get my passport, as well as the funds and passports to bring my wife and son to Ubuntu Summit.

That experience changed my life and the life of my entire family. My son, 10 at the time, was the youngest registered attendee. My wife was inspired to bring back Edubuntu, which had been defunct for nine long years by the time it was revived that following spring.

These are the things that happen when you have personal connections with people. If you’ve never read the book before, I encourage you to read Hardwired to Connect, which is a research paper published by a bunch of scientists. In essence, it says that people’s brains are wired, from birth, to engage in communities in for personal, in-person connections. It’s a scientific study that took years and is an excellent introduction to why we are the way we are.

Much of my education revolves around the very idea of building personal communities, which is one reason I was appalled when Ubuntu Summit, starting with 25.10, while it would be twice a year, it would be online-only except for the speakers. Having spoken at the past three, I was planning to take a year off from speaking, while still being there to represent as an Ubuntu Flavor Lead with my wife, also a now Flavor Lead.

If it weren’t for that initial Ubuntu Summit, in person, my wife and son would not have been as interested or as involved as they are today. The subsequent years only strengthened that involvement.

Now, it’s going to be an online-focused approach. I get it. It’s cheaper and easier. Also, those attending online were just watching a livestream anyhow. The Local Communities (LoCos) can get together on their own if they want to do a big event. It’s easier to reach more people if you do everything online.

Except it’s not.

For instance, the nearest active LoCo to me, in the Seattle-Tacoma area, is the Southern California LoCo. Meetups with them are logistically impossible. Same if I were to go to the Arizona LoCo; it’s just not possible. Most of the states in the United States are huge, so if there were one LoCo per state, it wouldn’t be correct. To be honest, I have no desire, time, or energy left to start and lead a LoCo in my area. Besides that, there used to be one for my state, but it’s long gone.

Furthermore, with the exception of me and my wife, us flavor leads are scattered to the globe. It used to be that we would meet online throughout the year every other month and then meet together once a year at Ubuntu Summit. That’s gone now.

Again, I get it. Canonical is a company that is and always has been majority remote work. Except for one thing: they get together twice a year in-person, and are even given T-Shirts to celebrate the immediately-prior release which was partially built by volunteers. Those of us who give our time, energy, and effort to the Ubuntu community aren’t given that in-person experience, let alone a T-Shirt. The very lifeblood of what makes Ubuntu so great isn’t given the ability to meet in-person. That’s been stripped from us, and it came as a complete surprise.

I’m not without ideas for solutions to problems, though. Rather than be completely destructive in this post, I can be constructive. My solution to this would be a compromise:

  • Have the Summit be in-person once a year following the yy.04 release
    • Have that one go back to being what it was. It can either have booths like 2024 did or go back to being talk/workshop-focused like years prior. It doesn’t matter, it just needs to be in-person.
  • Have the Summit be online once a year following the yy.10 release

I don’t think this is too much to ask. The reward of personal connections when doing something remote for most of the year is a small price to pay, no matter the cost. Personal connections are tantamount to a healthy community.

I think my compromise would prevent the Summit from dying just like the Ubuntu Developer Summit did once it went online-only. The way I see it is with the current status-quo, history is repeating itself.

I’m sure people at Canonical don’t see it this way because they meet with the people they work with the most twice a year. Those of us from the Ubuntu community that are developers aren’t given that luxury. We’re not even given that luxury once a year now. We’re not even given a T-Shirt!

Am I angry? A little. Do I feel betrayed by the very community I have given so much to over the years? Absolutely. Either way, I believe an online-only Summit is anti-collaborative in that it removes personal connections from the equation, which goes against the very fiber of my being.

Thank you for reading this, and I hope this reaches the people I’m trying to reach and have it speak for those who either won’t speak-up or don’t think they can make a difference.

Raspberry Pi as a Networked Audio Interface

I haven’t posted for quite some time, and a lot has happened. For instance, my wife revived Edubuntu and my work with Ubuntu Studio now spans over 7 years.

Recently, I became the proud owner of a Behringer X-Air XR18. This became the key to opening a new business, which I’ll announce at a later date. I’m working on acquiring more equipment to make this work.

As many people know, the XR18 is a stagebox-style mixer in which the mixer is physically on the stage with no controls but controlled with an iPad or Android tablet. However, as the owner of a Behringer X-Touch, which integrates seamlessly with an X-Air mixer via either MIDI or Network connections. In my situation, this gives the ability to have a physical front-of-house setup, with a computer showing the X-Air Edit application.

However, what if I want to multi-track record or add custom effects via Ubuntu Studio? This is where it would get complicated as I would then have to run a prohibitively-long USB cable from my computer to the XR18 on the stage. This would not be ideal.

As many people know, MIDI can be routed via network, which is the way the X-Touch, XR18, and X-Air app work together. A simple WiFi router and ethernet cable wouild be a great solution to this problem, but that also leaves an Ethernet cable prone to being tripped-over by audience members (unless one were to gaff it down). So, since we’ve already got WiFi, let’s take advantage of that.

To expose the audio ports to the WiFi, we’re going to have to bridge it. But… how? Most people would tell me just to use Dante but, unfortunately, Audinate refuses to support Linux, and AES67 support in PipeWire is very young. However, it turns out, JackTrip is in the Ubuntu repositories and, as its name would imply, integrates seamlessly with JACK and, therefore, PipeWire.

Setting this up is rather simple, and I’m documenting the process here.

Prerequisites

  • A Raspberry Pi 4 or higher (I have a late 2023 Raspberry Pi 5)
  • A micro SD card (16GB or larger)
  • Ubuntu Server for Raspberry Pi (I used 24.04, linked here).
  • Optional: Ubuntu Pro (for the RealTime Ubuntu Raspberry Pi Kernel)

Here we go…

The first thing I did was install the downloaded preinstalled server image to a micro SD card. This is accomplished using Raspberry Pi Imager. I used the Snap version maintained by Dave Jones of Canonical, part of Canonical’s Raspberry Pi team. If you’ve never met Dave, he does all of his computing via Raspberry Pi, and it’s a sight to behold!

To get that, it’s as easy as sudo snap install rpi-imager.

I made sure to set the server to automatically detect my WiFi, but if you plan to use a hard Ethernet connection, this isn’t necessary. Just be sure you can SSH into the machine as this is key (pre-set a user and set the machine name).

Once the SD card is imaged, I SSH’d into the machine (ssh erich@{computer-name}.local). The first thing I did was install jackd2 and jacktrip:

sudo apt install --no-install-recommends jackd2 jacktrip

One must use the --no-install-recommends option to avoid installing unecessary graphical tools as jackd2 will want to install qjackctl which is the GUI application to control JACK. We don’t need it here. JackTrip has an option to automatically connect to all inputs and outputs, so we’ll use that here.

To automatically start JACK upon boot, I modified this systemd unit file to be custom for my setup. You’ll notice I made the buffer 256 (-p 256) with 3 periods per buffer (-n 3) as gives the highest reliablility on a USB connection. Additionally, the highest frequency an XR18 runs at is 48000 Hz, so I made sure to set the frequency there (-r 48000). Also, we want the process to run in realtime and directly to ALSA (--realtime -dalsa):

[Unit]
Description=JACK server using %i user profile
Documentation=man:jackd(1)
After=sound.target local-fs.target

[Service]
User=%i
Group=%i
#Type=notify
EnvironmentFile=-/etc/jack/alsa.conf
#EnvironmentFile=-%h/.config/jack/%i.conf
ExecStart=/usr/bin/jackd --realtime -dalsa -p 256 -n 3 -r 48000
# -d $DEVICE $DRIVER_SETTINGS
LimitRTPRIO=95
LimitRTTIME=infinity
LimitMEMLOCK=infinity
# Caution: use on memory-limited devices only
# OOMScoreAdjust=-1000

[Install]
WantedBy=multi-user.target

I installed this to /usr/lib/systemd/system/jackd@.service.

Next, I created a systemd unit file to start JackTrip. I needed this to be a server (-s), with 18 inputs and outputs (for an XR18, -n 18) and automatically connect upon start (-q auto):

[Unit]
Description=JackTrip Audio Network Service
After=network.target sound.target jackd@%i.service
Wants=network-online.target

[Service]
# Run as a specific user who has JACK permissions
User=%i
Group=%i

ExecStart=jacktrip -s -n 18 -q auto --udprt
Restart=always
RestartSec=5

# Optional: environment for JACK if needed
#Environment=JACK_NO_AUDIO_RESERVATION=1

# Give JACK/JackTrip real-time priority
LimitRTPRIO=infinity
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

I installed this to /usr/lib/systemd/system/jacktrip@.service.

Next, to make sure this runs as my user, I did the following:

sudo systemctl enable jackd@erich.service
sudo systemctl enable jacktrip@erich.service

Optionally, since this will be used as a headless appliance, one can use Ubuntu Pro to get the RealTime Kernel. This is accomplished by the following with an Ubuntu One account:

pro attach
pro enable realtime-kernel

To make sure everything worked, check pro status.

You can have up to 5 machines running Ubuntu Pro for free. In my case, as an Ubuntu Member, I can have up to 50 machines for free, and this is only my third one!

Once this is done, reboot. On your other machine, install jacktrip-gui. (This will be in Ubuntu Studio 25.10 and higher by default!): sudo apt install jacktrip-gui.

Opening it, it will ask you if you want to sign in with a Virtual Studio account. This is because JackTrip allows you to collaborate across the entire internet with fellow musicians with very low latency! It’s pretty cool! However, we don’t need that for this purpose. Instead, we’re going to say “No” and simply connect to the server as a P2P client:

Enter the computer name with .local afterwards, and it should find it as long as your desktop or laptop is connected to the same network as the Raspberry Pi.

After you click “Connect”, you should see this:

As you can see, this has audio coming in from a microphone already.

Back in X-Air Edit, already connected to the mixer, I changed my routing so channels 1 and 2 were being sent to the aux, so I can then use my computer’s audio there for music from e.g. Spotify:

Next I started a Dummy Audio Device from Ubuntu Studio Audio Configuration and made it the main output for the computer. I then connected the monitor of the dummy output to channels 1 and 2 of JackTrip using Patchance:

…and VIOLA! Even testing my microphone, there was so little latency it was imperceivable.

I’m envisioning a setup like this:

I’m excited to test this further! Overall, I feel like I’ve found a way to do a Dante-less audio-over-ethernet setup that cost me nothing!