For sound output at my desk, I connect my dock to a digital audio receiver with a Toslink optical audio cable using S/PDIF. In this setup, the connection between my laptop and the reciever stops if there is no audio output for a while. This power saving measure is the road to hell that’s paved with good intentions: if audio output resumes for a notification sound, it takes the receiver about half a second before it starts playing. This delay cuts off the start of the sound.

To make matters worse, the amplifier in my subwoofer also has a power saving feature and turns off if it detects no output for a while.

To prevent this, I needed continuous sound output that would keep both the S/PDIF channel between my dock and my receiver open as well as my amplifier convinced that it’s still playing audio. At the same time, that audio stream should be as imperceptible as possible to me.

The open source ffmpeg library contains a configurable noise generator that can solve this problem. The anoisesrc audio source provides different “colors” of noise, and the mpv(1) player can play these sources. A small script called silence in my $PATH now prevents my receiver and amplifier from going into power saving:

#!/bin/sh
exec mpv av://lavfi:anoisesrc=r=44100:a=0.01:c=violet

I settled on the “violet” noise color (c=violet), because I found it to be the one I would notice the least. The a=0.01 parameter reduces the volume of the noise signal, while r=44100 sets the sample rate to 44.1 kHz.

For now, I start this script manually when I need it. I should probably automate starting it when my audio output is via S/PDIF and I’m not trying to use it for encoded output such as Dolby Digital or DTS, but I won’t let good enough be the enemy of perfect here.

Preamble

This is the third post in my series on my experiences at BMW Car IT GmbH. If you’ve missed the previous posts, you can find them in my archive.

In this post, I’m covering the use of open source software in the MGU head unit project at BMW.

Without open source software, there is no project

As I had already mentioned in my first post on the work I did at BMW Car IT GmbH between 2014 and 2021, BMW had gathered some 250 open source enthusiasts in Ulm and Munich to build an infotainment system for its cars released after 2018. This system would be a Linux system, and most of the userland resembled a modern Linux desktop distribution.

To distribute, or not to distribute, that is the question

This choice implied that BMW would respect the licenses of the various open source projects used in a typical Linux distribution. Almost all open source licenses have restrictions on what users must do when distributing the code in compiled or source code form. As a consequence, we had to figure out where BMW was “distributing.” The sale of a car that contains this code is obviously a distribution, but there were other cases to consider: BMW Car IT GmbH is a separate entity, so does passing a finished build to BMW AG constitute a distribution, even if BMW AG fully owns BMW Car IT GmbH? Furthermore, a series of companies were developing software for this platform, and developer tools—such as software development kits—were available in compiled form for download from our servers. That probably is “distribution,” and we would have to obey the license conditions. But would the companies BMW was paying to develop software for them sue over a license violation? Probably not.

This is the second post in my series on my experiences at BMW Car IT GmbH. If you’ve missed the first post, you can go back and read it here.

In this post, I’m covering missing binary compatibility and its effects on development processes.

The road to a recompile is paved with ABI incompatibilities

To exchange data between processes in its infotainment systems, BMW uses CommonAPI. CommonAPI was originally developed by the GENIVI alliance, which rebranded itself as the Connected Vehicle Systems Alliance COVESA in 2021.

CommonAPI allows specification of interfaces in the Franca Interface Definition Language FIDL independent of the message bus used to send and receive messages. It achieves this by generating C++ bindings from the interface description. These bindings then use a transport backend (CommonAPI supports DBus and Some/IP) that’s also compiled from generated code.

Seven years ago, I had just graduated from university and moved to Ulm to take a job at BMW Car IT to develop infotainment software for the (BMW) “cars of the future.” Last October, after four positions across three different teams, I have decided to move on. Time to recap.

Originally, I wanted to cover my entire career at BMW in this blog post. The first two and a half years would already fill a 2500 word essay, though, so I’ve decided to split these posts into a series of shorter posts. This first post covers my day-to-day work for the first two years in the software integration team.

A shift in how the automotive industry builds software

I joined right at the beginning of the development cycle for what would be the first infotainment system partly developed by BMW. The hardware part supplier—the so-called “Tier 1”—used to be fully responsible for development of the software of previous head unit systems, except for the BMW-themed user interface. BMW wanted to change this with the software targeting cars released in 2018. We can see the same transition taking place in other auto manufacturers, too: Daimler has Daimler TSS, which are now called “Mercedes-Benz Tech Innovation;” Audi founded e.solutions; Volkswagen founded CARIAD SE in 2020; Tesla has always been doing their software in-house.

Since I last switched phones, I no longer have root access to my Android. On my previous phone, I was using Titanium Backup, which—because it does require root access—is no longer an option. After I bought my current phone, I started using Swift Backup to avoid loosing my apps, messages, call logs and Wi-Fi networks.

That means that I do not have a backup solution in place for data: should my phone break, I would no longer have a copy of the downloads, pictures, and videos. I have been procrastinating a solution for this problem for about 2.5 years now. Time to stop.

What do I use on other systems?

On my workstations, laptops, and servers, I have been using borgbackup. It’s reasonably fast, has deduplication (which means I can run frequent backups), and a nice backup retention system. Contrary to some other tools, such as duplicity, there is no need to periodically create a fresh full backup to get yearly, monthly, and weekly backup retention policies. Also, backups are encrypted and authenticated. This is not super important for me since I run my own borgbackup server and thus do not have a strong trust boundary, but it feels like a good standard precaution to take.