fix(audio): resolve specific device names instead of generic driver class - #75
Merged
Conversation
…lass
Windows mic/speaker dropdowns were showing every device as an identical
generic label ("Microphone", "Microphone", "Microphone") after the cpal
0.17 migration (ac5651d, this session's Phase 4 stable-device-ID work).
Root cause: cpal 0.17.1's WASAPI backend sets description().name() from
DEVPKEY_Device_DeviceDesc, the driver-class label shared by every input
device using the same driver (commonly literally "Microphone"). The
per-endpoint specific name (DEVPKEY_Device_FriendlyName, e.g. "Microphone
(Realtek(R) Audio)") is only preserved as the first description.extended()
line, and only when it differs from the generic name. Previously
device_name() read only description.name(), discarding the specific name
entirely. cpal 0.16's Device::name() (removed in 0.17) returned the fuller
representation directly, which is why this wasn't visible before the
migration; device_names_match()'s own doc comment (e3df6f8) already notes
cpal 0.17 gives "the short" description vs 0.16's longer legacy one, but
only handled it for stored-selection matching, not for what gets displayed.
Fix: prefer the extended() line when present, falling back to name().
Confirmed via cpal's WASAPI source (device_description.rs) that extended()
carries FriendlyName exactly in the case that triggers this bug. The
existing device_names_match() bidirectional short/long matching already
reconciles this with any previously-stored device selections, so no
migration is needed for users who already picked a device under the
generic name.
Verification: compiles clean (cargo build), zero clippy findings in the
changed file. Could not execute `cargo test` locally — this dev machine
has Windows' own System32\onnxruntime.dll, which the ort/DirectML runtime
dependency (transcribe-rs's ort-directml feature) collides with at process
load time (STATUS_ENTRYPOINT_NOT_FOUND), unrelated to this change and
absent on CI's clean Windows runners where rust-tests has passed on every
PR this session. The two new unit tests were traced by hand against
DeviceDescriptionBuilder's documented behavior; CI is the actual gate.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GalaxyRuler
added a commit
that referenced
this pull request
Jul 13, 2026
Version bump + CHANGELOG so the cpal 0.17 friendly-name fix (#75) ships to users.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human Written Description
Reported by the user directly after updating: the microphone (and, by the same code path, output-device) dropdown showed every device as an identical generic label — "Microphone, Microphone, Microphone" — instead of real device names.
Root-caused (see commit message for full trace): this session's Phase 4 work (
ac5651dc, "stable device IDs via cpal 0.17") switcheddevice_name()insrc-tauri/src/audio_toolkit/audio/device.rsfrom cpal 0.16'sDevice::name()to cpal 0.17'sDevice::description().name(). Read cpal 0.17.1's actual WASAPI source directly:description().name()is populated from Windows'DEVPKEY_Device_DeviceDescproperty — the generic driver-class label every input device sharing a driver reports (frequently literally "Microphone"). The specific per-endpoint name (DEVPKEY_Device_FriendlyName, e.g. "Microphone (Realtek(R) Audio)") is preserved by cpal only as the firstdescription.extended()line, and only when it differs from the generic name —device_name()was discarding it entirely.Confirms this wasn't a new/unrelated bug:
device_names_match()'s own doc comment, added the very next commit (e3df6f8b) in the same phase, already noted cpal 0.17 returns "the short" description vs 0.16's fuller legacy name — the team had already observed the symptom but only worked around it for reconciling previously-stored device selections, not for what actually gets displayed to the user.Fix:
device_name()now prefersdescription.extended().first()(the specific FriendlyName, when cpal captured one) and falls back todescription.name()only when no more specific alternative exists. The existingdevice_names_match()bidirectional short/long matching (already used to resolve a user's previously-storedselected_microphoneagainst a freshly enumerated device list) already handles reconciling an old generic-named selection against the new specific name, so no settings migration is needed.Testing
cargo build(lib): compiles clean.cargo clippy --lib -- -D warnings: zero findings in the changed file (68 pre-existing findings elsewhere in the crate, unrelated).prefers_specific_friendly_name_over_generic_device_class_description,falls_back_to_generic_name_when_no_extended_line_present) constructed viacpal::DeviceDescriptionBuilder, traced by hand against its documented behavior.cargo testlocally: this dev machine has Windows' ownSystem32\onnxruntime.dll, which collides with theort/DirectML runtime dependency pulled in bytranscribe-rs'sort-directmlfeature at process load time (STATUS_ENTRYPOINT_NOT_FOUND) — reproduced with the entire test binary failing to launch (not test-specific), confirming it's a pre-existing machine/DLL-search-order issue unrelated to this change. CI's clean Windows runners don't have this conflict;rust-tests/ci-requiredhave passed on every PR this session. CI is the actual verification gate here.AI Assistance Disclosure
Bug reported by the user in this session immediately after receiving the v0.13.0 update. Root-caused and fixed by Claude Code by reading cpal 0.17.1's vendored WASAPI source directly and cross-referencing this repo's own Phase 4 commit history.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com