Naming was touched in https://invent.kde.org/plasma/plasma-pa/-/commit/dbeb64e3a69296eee7108c6218555655bea9ed4c

We've gone back and forth on this. It's a trade-off between "Trust the device not to have a stupid name" and "Overwhelm the user with nonsense jargon".

Currently we're trying the former. So ultimately this is probably a case where the devices themselves should have better names, which should be reported to the PipeWire folks at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues.

Regardless, does any more text to help disambiguate the devices  appear if you hover over the labels?

No. Hovering over the label does nothing.

Ok, that's not ideal. We can add more information on hover, the way we do for the case of only a single device.

But please also submit issues upstream to get better names for those audio devices!

I don't think there is anything wrong with the upstream names. They perfectly describe what the device name. The problem I'm having is the glance value.

If they perfectly describe the devices, then how is it that you're having trouble distinguishing the devices by name? Are your audio devices just very similar?

Yes, as the attachment shows they are very samey, which is why I requested to add the port type to the displayed name in the applet.

I am not seeing it. They have very distinct names identifying your monitor, your board, and your headest.

I am wondering if instead of fiddling with the global naming rules we should consider allowing the user to set custom names https://discuss.kde.org/t/renaming-of-audio-devices/16866 it may help solve many of the quirky naming problems at least on-demand.

Another option might be to have an advanced mode configuration where users can tick extra information they want to show in the delegates.
Opt-in verbosity.

[x] Product Name
[x] Device Description
[x] Mixer Name
[x] Bus

User-settable names sounds like a good improvement.

*** Bug 488917 has been marked as a duplicate of this bug. ***

*** Bug 488888 has been marked as a duplicate of this bug. ***

*** Bug 489070 has been marked as a duplicate of this bug. ***

I kind of dislike that Bug 488917 & Bug 488888 where marked as duplicate of this. 
I get that their background / "cause" is the same as Bug 487658 but..:

Bug 487658 says that the device names are "very samey" in Comment 7.
VS
While in Bug 488917 & Bug 488888 the device names ARE literally the same. 

I would argue that this much worse and makes this issue more urgent than Bug 487658 would makes it appear.

I created Bug 488888 thinking about all the users who don't know how to workaround this issue and are now unable to configure their audio devices because suddenly the names are exactly the same.

Thank you. Reporter of Bug 487658 here. Indeed in my case and in case of Bug 488888 we have professional audio recording interfaces that have 2 mono inputs but treated as 1 stereo input in hardware, thus they are separated through virtual devices defined in ALSA UCM rules (https://github.com/alsa-project/alsa-ucm-conf). What differentiates them is their description. Therefore we get a situation where both inputs literally look the same in the applet, making this issue a lot worse.

In my case both inputs looks like this:
- Volt 2
- Volt 2

And in the case of the other reporter it looks like this:
- UMC202HD 192k
- UMC202HD 192k

In our case it's not just "samey" but basically broken.

I understand the rationale behind the change and I fully agree that devices should have proper names but these are virtual devices created by UCM rules and I'm not sure if this should be fixed by the folks at PipeWire or ALSA. I think that in our end it should be either adjusted or given an advanced option to change what is shown to describe the device in the applet.

My apologies, I meant to say I'm the reporter of Bug 488917.

Thank you z411@omaera.org. You summarized the problem better than I could have. 

The point is that in my (our?) case the crucial information for being able to different devices is not stored in 'node.nick' but in 'device.profile.description' / 'node.description'. 
'node.nick' is exactly the same.

> wpctl status
> [...]
> Audio
> [...]
>  ├─ Sources:
>  │      52. UMC202HD 192k Input 2               [vol: 1.00]
>  │  *   65. UMC202HD 192k Input 1               [vol: 1.00]

> wpctl inspect 52
> [...]
> alsa.card_name = "UMC202HD 192k"
> device.profile.description = "Input 2"
> node.description = "UMC202HD 192k Input 2"
> node.nick = "UMC202HD 192k"

> wpctl inspect 65
> [...]
> alsa.card_name = "UMC202HD 192k"
> device.profile.description = "Input 1"
> node.description = "UMC202HD 192k Input 1"
> node.nick = "UMC202HD 192k"

Yes, that's exactly our case:

> alsa.card_name = "Volt 2"
> device.profile.description = "Mono Input 1"
> node.description = "Volt 2 Mono Input 1"
> node.nick = "Volt 2"

> alsa.card_name = "Volt 2"
> device.profile.description = "Mono Input 2"
> node.description = "Volt 2 Mono Input 2"
> node.nick = "Volt 2"

And this is how these virtual devices are defined in UCM rules:

> SectionDevice."Mic1" {
> 	Comment "Mono Input 1"

As you can see in this repository: https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2 - This is how rules in all cards supported by this project are defined. I'm not sure if they will want to change the workings of their entire subsystem just to accommodate Plasma's applet, and even if they do, it sure will take a while. This could also be handled by how things are handled on PipeWire's side so I don't know who I should raise the issue with.

For now I would kindly suggest for the priority of this bug to be raised and to find a workaround on our side as this is the only instance I've seen this being a problem.

@Comment 18

This is my workaround until I proper fix is being implemented.
I am manually overwriting the 'node.nick' property: 

> # File location:
> # /home/username/.config/wireplumber/wireplumber.conf.d/51-device-rename.conf
> 
> monitor.alsa.rules = [
>   {
>     matches = [
>       {
>         node.name = "alsa_input.usb-BEHRINGER_UMC202HD_192k-00.HiFi__umc202hd_mono_in_U192k_0_0__source"
>       }
>     ]
>     actions = {
>       update-props = {
>         node.nick = "UMC202HD Input 1"
>       }
>     }
>   }
>   {
>     matches = [
>       {
>         node.name = "alsa_input.usb-BEHRINGER_UMC202HD_192k-00.HiFi__umc202hd_mono_in_U192k_0_1__source"
>       }
>     ]
>     actions = {
>       update-props = {
>         node.nick = "UMC202HD Input 2"
>       }
>     }
>   }
> ]

I followed section 2.3 & 2.4 on the WirePlumber ArchWiki page: 
https://wiki.archlinux.org/title/WirePlumber#Obtain_interface_name_for_rules_matching
https://wiki.archlinux.org/title/WirePlumber#Changing_a_device/node_property

Thank you Moritz. I created an issue in PipeWire's tracker to see what they think.
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4077

I personally think that the description should be appended to the nick as you did automatically, but let's see if this is something that should be done in PipeWire or ALSA.

*** Bug 488875 has been marked as a duplicate of this bug. ***

Bug 488875 is also using a recording audio interface with virtual inputs so same issue. I also opened an issue in alsa-ucm-conf (https://github.com/alsa-project/alsa-ucm-conf/issues/426) but they say these names are not created by their rules but by PipeWire.

Created attachment 171052 [details]
Another applet screenshot

Another example here, this was perfectly read- and differentiable before, now USB Audio #1 and USB Audio #2 actually refer to different subdevices of two completely separate cards (one is the digital out of the integrated card, the other the Game Audio channel of the Astro Headset) and neither the chat channel  nor the game channel are clearly differentiable.

What about the "Description" field? Afaik this is officially intended to be an user facing descriptive string

Now that you mention it, in my other audio interface the description field is also a lot better than the nick.

> node.description = "D10 Headphones"
> node.nick = "D10"

Why isn't this used instead of the nick? Are there cases where the description is unusable?

Yep, can confirm that the `node.description` provides a better naming alternative for the device:

> $ wpctl status | grep Scarlett | grep Input | awk '{ if (match($0, /[0-9]+/, arr)) { print arr[0] } }' | xargs -I % wpctl inspect % | grep node.description
>  * node.description = "Scarlett Solo (3rd Gen.) Input 1 Mic"
>  * node.description = "Scarlett Solo (3rd Gen.) Input 2 Inst/Line"

Same problem here. The node.description field is much better, but even that isn't necessarily sufficient to distinguish between source and sink devices.

In the following output, `node.nick` is what is currently shown. Note the description is *much* better, but that would still not differentiate between the Arctis 7 wireless adapter Chat sink and source, which have exactly the same description.

Funnily enough, the System Settings / Sound page does it mostly fine. It differentiates Playback and Recording devices into separate sections, and shows the descriptions of each device.

```
$ pw-dump | jq '.[] | select(.type == "PipeWire:Interface:Node" and .info.props["node.nick"] != null) | { "node.nick": .info.props["node.nick"], "node.description": .info.props["node.description"], "media.class": .info.props["media.class"], "device.disabled": .info.props["device.disabled"] }'

{
  "node.nick": "HD Pro Webcam C920",
  "node.description": "HD Pro Webcam C920 Pro",
  "media.class": "Audio/Source",
  "device.disabled": null
}
{
  "node.nick": "HD Pro Webcam C920",
  "node.description": "HD Pro Webcam C920 (V4L2)",
  "media.class": "Video/Source",
  "device.disabled": null
}
{
  "node.nick": "USB Audio #3",
  "node.description": "USB Audio S/PDIF Output",
  "media.class": "Audio/Sink",
  "device.disabled": true
}
{
  "node.nick": "USB Audio #1",
  "node.description": "USB Audio Front Headphones",
  "media.class": "Audio/Sink",
  "device.disabled": null
}
{
  "node.nick": "USB Audio",
  "node.description": "USB Audio Speakers",
  "media.class": "Audio/Sink",
  "device.disabled": null
}
{
  "node.nick": "USB Audio #2",
  "node.description": "USB Audio Microphone",
  "media.class": "Audio/Source",
  "device.disabled": null
}
{
  "node.nick": "USB Audio #1",
  "node.description": "USB Audio Line Input",
  "media.class": "Audio/Source",
  "device.disabled": null
}
{
  "node.nick": "SteelSeries Arctis 7",
  "node.description": "Arctis 7 wireless adapter Chat",
  "media.class": "Audio/Sink",
  "device.disabled": null
}
{
  "node.nick": "SteelSeries Arctis 7",
  "node.description": "Arctis 7 wireless adapter Chat",
  "media.class": "Audio/Source",
  "device.disabled": null
}
```

In addition (and I guess this may be a separate issue) but KDE ignores the Pipewire "device.disabled" property.

*** Bug 489858 has been marked as a duplicate of this bug. ***

Git commit eae94ed4f1eb62276fd27c4477347efe17127d90 by Harald Sitter.
Committed on 31/08/2024 at 02:40.
Pushed by sitter into branch 'master'.

allow user to rename devices and select a preferred name source

# Name Source

Allows choosing the name out of a set number of sources. Names have been
unified across applet and kcm now.
Changes here are instantly applied throughout the stack.

# Overrides

Additionally, overrides may be set. These override all supported name
fields so it doesn't matter which name source is chosen at the time the
change is made. The override installs a wireplumber json file and
restarts the stack to apply the change.
Related: bug 491205, bug 488897

M  +6    -1    applet/contents/ui/main.qml
M  +3    -0    src/CMakeLists.txt
A  +66   -0    src/devicenamesourcemodel.cpp     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
A  +27   -0    src/devicenamesourcemodel.h     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
A  +141  -0    src/devicerenamemodel.cpp     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
A  +30   -0    src/devicerenamemodel.h     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
A  +320  -0    src/devicerenamesaver.cpp     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
A  +49   -0    src/devicerenamesaver.h     [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)]
M  +10   -0    src/globalconfig.kcfg
M  +1    -0    src/globalconfig.kcfgc
M  +17   -1    src/kcm/ui/DeviceListItem.qml
A  +267  -0    src/kcm/ui/RenameDevices.qml     [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
M  +10   -0    src/kcm/ui/main.qml
M  +14   -0    src/qml/plugin.cpp

https://invent.kde.org/plasma/plasma-pa/-/commit/eae94ed4f1eb62276fd27c4477347efe17127d90

(In reply to Harald Sitter from comment #28)
> Git commit eae94ed4f1eb62276fd27c4477347efe17127d90 by Harald Sitter.
> Committed on 31/08/2024 at 02:40.
> Pushed by sitter into branch 'master'.
> 
> allow user to rename devices and select a preferred name source

I'm not familiar with this code, but I'm not seeing anywhere in this PR where it takes care of differentiating between devices with the same name/description but different media class (sink vs source). Is that considered a separate issue?

(In reply to Raman Gupta from comment #29)
> (In reply to Harald Sitter from comment #28)
> > Git commit eae94ed4f1eb62276fd27c4477347efe17127d90 by Harald Sitter.
> > Committed on 31/08/2024 at 02:40.
> > Pushed by sitter into branch 'master'.
> > 
> > allow user to rename devices and select a preferred name source
> 
> I'm not familiar with this code, but I'm not seeing anywhere in this PR
> where it takes care of differentiating between devices with the same
> name/description but different media class (sink vs source). Is that
> considered a separate issue?

I'm not sure I follow, what's the issue here? Checking your example pw-dump, the sources (i.e. microphones) seem to clearly differentiate which they are in the description field? In any case, the point of this PR is that you'll be able to configure this yourself as well with whatever you want if need be.

Visually a source and a sink are already differentiated in the applet by a line separator splitting sinks and sources.

(In reply to David Roth from comment #30)
> Visually a source and a sink are already differentiated in the applet by a
> line separator splitting sinks and sources.

Ooh, I see the separator now. I completely missed it before. Its *very* subtle. Ok, well now that I know it is there, all good.

I've seen the commit and it does seem it would resolve this issue. Although I would personally prefer that the description were the default, rather than the nick. I've a USB DAC, my motherboard input/output and sound via HDMI. 

`27B2` and `ALC1220` doesn't really make *much* sense for a device name.

As an experiment, I won't say which one is which as it would then represent an actual situation where you don't know the devices.

Using description, I was able to differentiate the devices without an an issue. Using nick I have to experiment.

Looking at the code above, it only seems like you're able to change it on the user-level and you have to do it for evert device one by one , rather than being able to set it on the system level as a default for all devices.

(And I would also prefer that you have to swap from description->nick by hand, rather than the other way around (using nick doesn't make much sense))

(In reply to Zastrix Arundell from comment #32)
> I've seen the commit and it does seem it would resolve this issue. Although
> I would personally prefer that the description were the default, rather than
> the nick. I've a USB DAC, my motherboard input/output and sound via HDMI. 

I wish bugzilla had a reactions mechanism. Absolutely +1 on this.

The customization is appreciated but I also agree the description should be the default. That's the field intended for this use case and several users have reported here that using the nick causes issues for a lot of devices.

Actually looking at it, it won't fix the issue for which the ticket has been opened. A new installation will still have the same names if the device had multiple inputs/outputs. The user has to actively go and do some settings shenanigans in order for it to work.

If the bug were opened as something like "I can't see my cursor but it does point/click" and the PR for it was "go to settings under X > Y > Z and allow for the mouse to have textures enabled" I wouldn't say that it was a proper solution to the problem. I would say it's a workaround -- just as I would for the PR. It's a nice feature, but doesn't FIX the underlying problem -- it just allows for the user to fix it. 

If it's REALLY insisted to use Nicks (which is a bad decision IMHO) at the very least description should be used when there's 2 same Nicks. 

I'll see to create a PR to change the default to Description, as it seems like literally a single-line PR.

Switching to the description by default when nicks are identical seems like it makes sense.

(In reply to Nate Graham from comment #36)
> Switching to the description by default when nicks are identical seems like
> it makes sense.

If the nicks are identical shouldn't wireplumber fix them?

You're saying you think this is a Wireplumber bug that they should fix rather than us working around it?

(In reply to Nate Graham from comment #38)
> You're saying you think this is a Wireplumber bug that they should fix
> rather than us working around it?

Whether identical nicks are an upstream problem or not doesn't really matter. Nicks are generally less useful as UI descriptors than "description" is, whether they are identical or not. Compare this list from my system:

Nicks (sources and sinks separated by ---):

USB Audio #3
USB Audio #1
USB Audio
SteelSeries Arctis 7
---
USB Audio #2
USB Audio #1
SteelSeries Arctis 7

with this list of corresponding descriptions:

USB Audio S/PDIF Output
USB Audio Front Headphones
USB Audio Speakers
Arctis 7 wireless adapter Chat
---
USB Audio Microphone
USB Audio Line Input
Arctis 7 wireless adapter Chat

Which list would you rather see? I don't think my system is the outlier here.

(In reply to Nate Graham from comment #38)
> You're saying you think this is a Wireplumber bug that they should fix
> rather than us working around it?

Well, it's at least worth talking to them. If the nick is worthless that seems like the real problem.

https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/720

(In reply to Nate Graham from comment #41)
> https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/720

To summarize the reply from wireplumber upstream here:

* Description is upstream's intended field for UI display, not nick
* Both descriptions and nicks are created based on a Lua rules system which may be sub-optimal for some devices
* They welcome contributions to improving the rules system and potentially adding a database or even potentially AI-driven naming -- visit the issue above for more details

Conclusions for KDE seem pretty clear to me:

* Use description by default for UI display
* Let users choose to override the description (or use the nick) on a per-node basis

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/286

Git commit 2f884ba5d95bbb8119f003aa0f916c37e9785edd by Harald Sitter.
Committed on 30/09/2024 at 13:37.
Pushed by sitter into branch 'master'.

use description as per upstream recommendation

if description is too verbose or technobabble this needs taking up
stream

M  +1    -1    appiumtests/applettest.py
M  +8    -3    applet/contents/ui/main.qml
M  +2    -2    src/devicenamesourcemodel.cpp
M  +1    -1    src/globalconfig.kcfg
M  +8    -3    src/kcm/ui/DeviceListItem.qml
M  +11   -4    src/kcm/ui/RenameDevices.qml
M  +0    -5    src/kded/audioshortcutsservice.cpp

https://invent.kde.org/plasma/plasma-pa/-/commit/2f884ba5d95bbb8119f003aa0f916c37e9785edd

Git commit 73535c4a6acd4bd177e526adb0f084027bcc936d by Harald Sitter.
Committed on 02/10/2024 at 11:43.
Pushed by sitter into branch 'Plasma/6.2'.

use description as per upstream recommendation

if description is too verbose or technobabble this needs taking up
stream
(cherry picked from commit 2f884ba5d95bbb8119f003aa0f916c37e9785edd)

M  +1    -1    appiumtests/applettest.py
M  +8    -3    applet/contents/ui/main.qml
M  +2    -2    src/devicenamesourcemodel.cpp
M  +1    -1    src/globalconfig.kcfg
M  +8    -3    src/kcm/ui/DeviceListItem.qml
M  +11   -4    src/kcm/ui/RenameDevices.qml
M  +0    -5    src/kded/audioshortcutsservice.cpp

https://invent.kde.org/plasma/plasma-pa/-/commit/73535c4a6acd4bd177e526adb0f084027bcc936d

Just installed 6.2 on Fedora 40… works great! Thank you.