Debugging audio issues with my Bose speakers

I recently switched from OpenSUSE to NixOS. The migration was pleasantly smooth, but after a couple of weeks I started to notice occasional spikes in the system volume when playing audio. I figured this was related to something about my NixOS configuration¹, but the spikes were rare enough that I didn’t bother trying to track the issue down.

After getting back from a trip, the volume spikes became much more frequent, and I decided to figure out what the problem was. As I started debugging, I decided I should keep notes — even if my findings didn’t end up being useful to others, I hoped my general process could be.

Setup

When debugging, I like to start with a clear problem statement to stay focused. Ideally this is paired with an easy way to reproduce the problem, but that’s not always feasible. Luckily, this situation was pretty straightforward to describe and to reproduce.

The problem

When playing audio, the volume would occasionally significantly increase, going from a (subjective) 60dB² to a (subjective) 85 dB³. It would remain at that level for an indeterminate amount of time, ranging from fractions of a second to ~15 seconds, then return to my desired volume level.

Reproducing it

When I started debugging this, the issue was occurring several times a minute with no input required from me. While this type of reproduction would be really annoying if the frequency was low, it was quite nice in this case since I could quickly see the impact of my changes even while behind my desk plugging and unplugging hardware.

Debugging process

Most of the time, things break after they’ve been changed. As such, I started by looking at what had changed in my setup recently. This was a bit confusing, since I’d actually been on the East coast for a week, during which time my desktop had been hibernating and distinctly unchanged. However, I had made some seemingly-unrelated changes to my NixOS configuration shortly before leaving, so I started there.

I searched for NixOS audio issues, but found nothing that sounded related other than some ancient forum threads. Since my hypothesis was that an update could’ve caused this, I quickly skimmed the threads from 2011 then proceeded to ignore them. Similarly, a look at recent NixOS issues in nixpkgs yielded no results.

While searching, I saw a few complaints about audio output on AMD hardware (I’m running an AMD 7950X). I looked a bit for more information, but didn’t find anything that looked particularly compelling. However, this made me think that I should determine whether this could be an issue in a driver/hardware or elsewhere in the Linux audio stack.

I brought up pavucontrol and watched to see if the volume changed on any outputs. The volume always showed 100% (as desired), even when spikes were occurring. Just to be sure, I checked some wikis and learned about pw-top for seeing information about pipewire playback. I wasn’t really sure how to use it, but it was pretty easy to see that nothing was changing during the volume spikes. These two tests told me that there was probably nothing going on at the pipewire level, so I guessed I’d need to look deeper into the kernel.

Next, I realized that I hadn’t actually rebooted in a while. I knew that hibernation could bring out bugs, since my mouse occasionally loses the ability to scroll after a wake-from-hibernate, so I rebooted to try to rule out improper device handling. The issue immediately occurred on reboot.

While thinking about it, I realized that I’d only encountered the spikes in my music player. I verified that this was a system-wide issue by playing a music video in Firefox. I also realized that I hadn’t tried unplugging and re-plugging the speaker, so quickly tried that to no avail.

At this point, I was leaning towards a driver issue. uname -a showed that I was on Linux 6.12, and a few threads mentioned having audio troubles on that kernel version, so I switched my machine to use pkgs.linuxPackages_latest (Linux 6.17) and rebuilt. The issue continued to reproduce.

A decent idea (finally)

I finally had a good idea and tried switching outputs from my speakers to my monitor via HDMI, and the issue stopped reproducing. I obviously wasn’t happy with this solution⁴, but I’d found my first hint and knew I was now making progress! I was a bit annoyed that I hadn’t considered trying this earlier, since it was an easy way to rule out most of the tests I’d already done, but such is life.

I now remembered that issues aren’t necessarily only in software, and expanded my potential issue to either be in a driver or something related to the speakers themselves. I dug up an old pair of wired headphones and listened for a few minutes before concluding that the issue wasn’t reproducing with these. Now I knew something on the way from the output port to the speaker was incorrect.

I quickly tested a different 3.5mm cable, coming to the final conclusion that the speaker itself was causing the volume spikes. Searching for “Bose Companion 2 Series III volume spikes” quickly showed a host of other people with the same problem.

Resolution, or lack thereof

It appears that Bose Companion 2 Series III speakers have an issue where grime builds up internally by the volume knob, causing problems for a variable resistor and acting like the volume knob is periodically spun high. These speakers are out of warranty and not really user-repairable, and I can’t remove the (theoretically removable) volume knob non-destructively.

Luckily, I have a second set of the exact same speakers for reasons. For now, I’ve switched out the master speaker while I figure out how to repair the broken one. People online seemed to have some luck with alcohol and a hacksaw⁵.