# Sound Output Device Chooser for GNOME Shell and the Python detection switch behind it

> kgshank's GNOME Shell extension puts audio input and output selection in the shell menu instead of the settings panel, but its newer profile identification logic depends on Python and its old fallback only reads English display strings.

**kgshank/gse-sound-output-device-chooser** — Gnome Shell Extension to show a simple chooser to select Input & Output device based on gnome control center

- Repository: https://github.com/kgshank/gse-sound-output-device-chooser
- Website: https://extensions.gnome.org/extension/906/sound-output-device-chooser/
- Stars: 785 · Forks: 100
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/kgshank-gse-sound-output-device-chooser

## A menu entry for devices that GNOME hides inside the settings panel

Switching audio output on a Linux desktop normally means opening the sound section of the settings application, finding the output device list, and confirming the change. On a laptop with speakers, headphones, a monitor over HDMI and a Bluetooth headset, that path is repeated several times a day, and the settings application offers no keyboard shortcut for the part that matters.

kgshank/gse-sound-output-device-chooser is a GNOME Shell extension that places a simple chooser for input and output devices directly in the shell. The description calls it a chooser based on the gnome control center, and the project states that it offers "a simple selector to enabled selection of sound source and sink". The scope is deliberately narrow. It does not mix in per-application routing, it does not add equalizer controls, and it does not try to be a sound mixer. It exists for the case where one person, one desktop, several sinks, and a lot of repetition.

The target user is therefore specific rather than broad. Anyone who changes output devices once a month will not get much from it. Anyone who moves between a desk setup and a meeting room every afternoon probably will. The extension is also the kind of tool that a distribution packager or a colleague sharing a dotfiles repository would install as part of a larger desktop configuration.

## Profile identification switched from English labels to a Python helper

The most interesting decision inside this repository has nothing to do with the menu. It is the identity logic that decides which entries belong in the chooser at all.

The project describes the dependency as "Python 2 or 3", and adds that the new version needs Python as an optional dependency. That optional framing is the key. The newer profile identification logic can be turned off with an option, which lets the extension fall back to the old logic. The tradeoff is stated plainly: the old logic has a language dependency and works only with an English display language.

So there are two detection paths with different requirements. The current path is script assisted and locale independent, at the price of requiring Python on the machine. The fallback path needs no helper process, but it matches device names as the system presents them in English, so on a desktop running another display language it will not find profiles the way the current path would. The project does not document the internal format of the profile list or the exact contents of the Python helper, so the mechanics of the match cannot be confirmed from the repository files alone.

For an engineer, this is the part to test first rather than the menu itself. If the chooser shows fewer devices than the settings panel on your system, the detection mode is the first thing to inspect.

## Installing from source by hand when the extensions app is not enough

The project names extensions.gnome.org as the official installation method. When you want the repository version instead, the README describes copying the extension directory into the shell extensions path yourself. The sequence below is taken verbatim from the project instructions. It clears out any earlier copy of the extension, clones the repository, copies the UUID directory into place, and removes the clone.

```bash
cd ~/.local/share/gnome-shell/extensions/

# Remove older version
rm -rf *sound-output-device-chooser*

# Clone current version
git clone https://github.com/kgshank/gse-sound-output-device-chooser.git

# Install it
cp -r gse-sound-output-device-chooser/sound-output-device-chooser@kgshank.net .
rm -rf "gse-sound-output-device-chooser"
```

The first command is a removal pattern, so it is worth checking what matches before running it in a directory that holds other extensions. The project expects the extension to carry the UUID `sound-output-device-chooser@kgshank.net`, and the top level of the repository holds that directory alongside the build files.

A Makefile in the repository root mirrors the same layout. Its variables and source directory are defined as follows.

```makefile
INSTALL_DIR=~/.local/share/gnome-shell/extensions
SRC_DIR=sound-output-device-chooser@kgshank.net
```

The build target compiles translation files with glib-compile-schemas and the install target copies the source directory into the install location. Separate enable and disable targets call gnome-extensions with that same UUID, which is the command line path to turning the extension on without opening any interface. Either path ends the same way: the extension is enabled from the GNOME Extensions App, and a shell restart is advised if errors show up.

## A compatibility list that stops at older shell versions

The project publishes an explicit list of shell versions it supports: 43, 42, 41, 40, 3.38, 3.36, 3.34 and 3.32. For anything older, the project sends you to the extensions.gnome.org page instead of the source repository. This is a normal split for shell extensions, where the internal APIs shift between major releases, and the list tells you exactly where the source install stops being the sensible route.

The list is also a mirror of the release history. The recorded releases are version 43 on 2022-04-22, version 42 on 2022-04-08 and version 39 on 2021-11-14. The version numbers track GNOME Shell releases, and the last push was on 2026-06-10. The repository is not archived.

Nothing in the project files documents a support policy for shell versions newer than 43, so on a current desktop the extensions.gnome.org build is the more conservative choice, since that page is where the project says older and newer combinations are handled. What the project supports is narrower than a promise of ongoing compatibility: it supports the observation that the last push landed on 2026-06-10, and that the newest tagged release in the list dates from 2022.

## Volume menu conflicts are the documented failure mode

The notes attached to the project are short, and one of them is a warning: the extension "May conflict with extensions which modify volume menu." That is the failure mode to plan for, because the extension inserts itself into the same region of the shell interface that other audio extensions rewrite.

The second note gives the mitigation for one specific pairing. The extension works with the Volume Mixer extension, and the advice is to restart the shell if errors are encountered. That is a narrow statement about a narrow combination. It does not cover every extension that touches the volume menu, and the word may in the conflict note is doing real work: the behaviour is a documented possibility rather than a confirmed breakage.

The practical reading is that if you already run an extension that customises the volume menu, install this one on a session you can recover from. The project gives you the shell restart instruction, and it gives you the enable and disable commands, so a misbehaving combination can be turned off without editing files. Nothing in the documentation offers a resolution order or a conflict matrix, which means diagnosing a bad interaction means removing candidates one at a time.

## Where the native settings panel remains the better tool

There is a real alternative for this job, and it ships with the desktop. The gnome control center sound panel is where the system enumerates sinks and sources, where a stream can be balanced, and where output settings such as device profile and volume live. The extension description itself points at that panel as the basis for its chooser.

The difference in approach is one of placement and scope. The settings panel is a full application view with descriptive labels and per-device controls. The chooser is a shell menu aimed at the act of switching, which is why it can also act on input devices, since panels tend to bury input selection further down. The extension offers no equalizer, no per application routing and no configuration UI of its own, and the project does not document one.

There is also a system level path that avoids the shell entirely: the command line audio utilities that ship with PulseAudio or PipeWire can switch the default sink without any GUI. That path suits scripts and remote sessions, where a shell menu is not available at all.

So the extension earns its place only when the panel is the bottleneck. For anyone who changes output a few times a month, the native panel is faster to reach and carries more controls. For someone switching several times a day across several devices, a two click menu from the top bar is a genuine saving.

## What a licence choice means when you redistribute it

The project is distributed under GPL-3.0, which is recorded in the LICENSE file at the root of the repository and in the project listing. Version 3 of the GNU General Public License is a copyleft licence, so anyone who distributes the extension, whether as a packaged install, a tarball or a copy placed on another machine, has obligations regarding the source and the licence text of what they ship.

The repository includes a CHANGELOG.md and a build directory alongside the extension source, plus locale files and a translation template target that produces `sound-output-device-chooser.pot` and compiles per locale `.po` files into `.mo`. The build rules rely on the gettext tools, which is worth knowing if you plan to package the extension for a distribution rather than install it for yourself.

This is not legal advice and the licence text is the authority. The practical point for an evaluator is narrow: because the extension is GPL-3.0, distributing it inside a distribution image or a curated setup repository is a different undertaking from installing it from extensions.gnome.org for your own account, and the obligations differ.

## Conclusion

Adopt this extension if your machine has several audio sinks and you switch between them daily, and if you are comfortable enabling a shell extension that depends on a helper script. Skip it if you already live inside gnome control center, if you cannot install Python and want the extension to work outside English locales, or if other extensions rewrite the volume menu, since the project's own notes flag a conflict there. Verify first that your GNOME Shell version appears in the compatibility list, that the extensions app can enable the extension after a shell restart, and that the language setting matches the detection mode you intend to use.

## FAQ

### Do I need Python to use the sound output device chooser extension?

Only for the newer profile identification logic. The project lists Python 2 or 3 as a dependency and describes the newer logic as requiring Python as an optional dependency, with an option to turn it off, in which case the old logic runs instead but works only with an English display language.

### How do I install gse-sound-output-device-chooser from source?

Clone the repository into `$HOME/.local/share/gnome-shell/extensions`, copy the `sound-output-device-chooser@kgshank.net` directory into that location, remove the clone, and then enable the extension from the GNOME Extensions App. The project names extensions.gnome.org as the official installation method.

### Which GNOME Shell versions does the sound output device chooser support?

The project lists versions 43, 42, 41, 40, 3.38, 3.36, 3.34 and 3.32 for source installs, and directs users of older versions to the extensions.gnome.org page.

### Why does the chooser show fewer devices than my sound settings panel?

The likely cause is the detection path in use. With the newer profile identification logic turned off, the fallback path depends on English display names, so on a non English locale it will not find the same profiles the settings panel shows.

### Can this extension conflict with my other audio extensions?

The project notes that it may conflict with extensions which modify the volume menu, and states that it works with the Volume Mixer extension. If errors appear, the project advises restarting the shell.

## Sources

- [kgshank/gse-sound-output-device-chooser on GitHub](https://github.com/kgshank/gse-sound-output-device-chooser)
- [License: GPL-3.0](https://github.com/kgshank/gse-sound-output-device-chooser/blob/master/LICENSE)
- [Project website](https://extensions.gnome.org/extension/906/sound-output-device-chooser/)
- [README](https://github.com/kgshank/gse-sound-output-device-chooser/blob/master/README.md)
- [Releases](https://github.com/kgshank/gse-sound-output-device-chooser/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kgshank-gse-sound-output-device-chooser