Why I built Timbre to keep my audio hardware useful

I started Timbre because I wanted to keep using the microphone and sound card I already had.

EPOS was winding down its gaming business, and I had trouble getting Gaming Suite from its website. I already had the software installed on another machine, so I had a working setup to learn from. What I wanted was a way to keep using these products even if obtaining the software or maintaining that setup became harder.

EPOS's gaming portfolio announcement describes the phase-out and still points people toward support. It does not give a Gaming Suite shutdown date. My trouble getting the download was a personal experience. It was enough to make me think about how much of a device's useful life depends on having access to its software.

I was also seeing the same products still for sale, often much cheaper than their original prices. There was useful hardware here. I wanted to understand how to keep its capabilities available.

The sound card that was doing less than I thought

One of the most useful discoveries came from my own GSX 300.

It produced sound. My headset worked through it. That made the installation look functional. During the investigation, though, we found that it was using a generic Windows USB audio driver and that the EPOS processing component was not registered on its microphone and playback endpoints.

I had been missing a group of features without really understanding that they were absent.

Selecting the compatible EPOS driver already installed on the machine and rebooting changed that. The processor appeared on the endpoints, playback exposed eight channels, and the effects started making an audible difference. I confirmed the gate, noise filter, EQ, virtual 7.1, and reverb by listening. Later tests measured specific gate and EQ changes as well.

The important detail was the missing processing registration on this installation. Windows can support manufacturer effects alongside its class drivers; a generic driver name alone does not settle whether a device has its effects. Microsoft's audio processing architecture documentation explains how manufacturers add software effects to the audio path.

That discovery gave the project a very practical purpose. I could recover capabilities in hardware I already owned, then make them easier to use.

Profiles for what I am doing

The app I wanted was straightforward: let me switch the relevant audio settings together depending on what I am doing.

That does not always mean changing everything connected to the computer. My microphone can be the B20 while my headphones are connected through the GSX. A setup profile should be able to include the B20 microphone and GSX playback while leaving other pages alone.

Timbre now has device profiles for an individual audio page and setup profiles for selected pages across devices. Live edits apply by default, and saving a named profile is an explicit action. That matters because experimenting with an EQ curve should not quietly rewrite a setup I intended to keep.

These are small decisions, but they are the reason to build a tool I will actually use. The investigation serves the daily workflow.

Learning by taking it apart

I also wanted to learn some new technology.

How does Windows identify an audio endpoint? Which controls belong to the device, and which are processing on the PC? What does the USB interface expose? How does a control app tell a separate audio processor that a setting changed?

Memory mapping became part of that learning. We investigated shared control buffers, the fields that changed when I moved a control, and the synchronization objects used around them. Understanding the layout was only the start. We also had to consider startup, device removal, competing edits, and what happens when the process holding those objects goes away.

I wanted to understand the design choices well enough to maintain my own interface. We can observe how this system behaves and infer why a design might be useful; the original engineers' intent is still an inference.

Maintaining it with my agents

Coding agents helped turn the investigation into source code, tests, and documentation. I supplied the hardware, the use cases, and listening confirmation. The work became more useful when we kept the evidence behind each implementation close to the code.

That means keeping reviewed control captures, checking the bytes we change, retaining failed experiments, and writing down what a result actually establishes. A future agent should be able to see why a control exists and which assumptions it relies on.

Timbre still uses compatible installed EPOS driver and processing components. Normal app use also depends on vendor background support. Experimental helpers have made progress with that support temporarily stopped, but an independent driver or processing engine is a separate project. I want continued access to the hardware's capabilities; I am documenting the dependencies we still have.

The original code is now shared under MIT in the Timbre GitHub repository. The project page describes the current controls, and the validation notes track what we have checked on my machine.

I started with a download problem. I ended up learning more about the sound card I was already using, recovering features I had overlooked, and building a tool I can keep improving. That is the kind of software I want to make.