Timbre

I built Timbre because I wanted to keep using audio hardware I already owned, and I wanted to understand how it worked.

EPOS was winding down its gaming portfolio, and I had trouble getting Gaming Suite from its website. I already had a working installation on another machine. I was also seeing these devices still for sale at much lower prices than when they launched. That made continued access to their capabilities worth investigating. EPOS describes the portfolio phase-out on its gaming page; my download difficulty was my own experience, rather than evidence of a specific software shutdown date.

Timbre grew from that investigation into a native Windows app for my B20 microphone and GSX 300 sound card. Its name leaves room for the idea to extend beyond one manufacturer: audio controls and profiles for hardware worth keeping.

What it does today

• Microphone controls: level, mute, gate/filter, and nine-band EQ for the B20 and GSX 300. The B20 also has high-pass filtering and separate hardware monitoring mute. Both have supported sidetone level controls.
• GSX playback controls: Windows volume/mute, stereo or virtual 7.1, nine-band EQ, and reverb. My analog GSP 301 headset uses the GSX endpoints.
• Profiles for the activity: a device profile saves one audio page; a setup profile combines selected pages across devices. I can pair the B20 microphone with GSX playback without also changing B20 playback.
• Explicit saves: live edits apply by default, while named profiles change only when I save them. Microphone and playback activity views are opt-in and save no recordings.

The screenshot shows the actual WPF interface using demo devices and settings.

What the investigation uncovered

My own GSX 300 was using a generic Windows USB audio driver. Basic sound worked, but the EPOS processor was missing from the endpoints. Selecting the compatible installed EPOS driver and rebooting exposed a group of features I had not understood I was missing. We subsequently checked controls, listened to the effects, and measured specific changes in the audio.

That discovery shaped the work. A useful control app needs to understand device identity, the installed processing path, and whether a change reaches the audio stream.

How we are building it

I am developing Timbre with coding agents. We capture one control change at a time, compare the shared settings, record the evidence, and test that an update preserves everything it does not own. Offline regressions and demo UI checks are separate from opt-in hardware experiments.

The source, protocol notes, reviewed fixtures, and failed experiments are part of the project. I want enough knowledge recorded to keep maintaining the tool as the original support situation changes.

Where it stands

This is an experimental personal tool with local hardware evidence. Normal use still requires compatible installed EPOS driver/processing components and Gaming Suite background support. Separate helpers have demonstrated bounded initialization and specific audio effects with vendor support temporarily stopped on my PC. They still use the installed EPOS audio processor.

Cold boot, an installed replacement service, broader compatibility, and an independent driver or processing engine remain future work. See the current validation record for the exact boundaries.

Source and build notes

Explore Timbre on GitHub, start with the README, or read the documentation index. Source builds target Windows x64 and .NET 9; the repository explains the runtime and vendor dependencies.

Original project code is MIT licensed. Vendor installers, drivers, processing binaries, raw local captures, and personal profiles are excluded. Third-party notices explain the separate provenance of reviewed research fixtures. Timbre is an independent project.

The story continues in why I built Timbre and what testing Windows audio with coding agents taught us.