[pulseaudio-discuss] update-card-properties? Possible?

[Tanu Kaskinen]

On Tue, 2016-08-16 at 23:06 +1000, Bernd Wechner wrote:
> Thanks Tanu, your observations are every very helpful and time saving.
> 
> If I may, I'd ask an ancillary question. It's not actually the card's 
> device.description I want to change. I just had a curious question about 
> that because that is what is used at present by the Sound settings app 
> in Linux MINT (Cinnamon) to identify sound devices.
> 
> Only I find that wholly inadequate and have the strong desire to name my 
> sound devices as I manage quite a number and even in the simplest case 
> of two onboard sound devices on a NUC the names not at all useful in 
> identifying which is which on the ports.
> 
> The use-case I'm after is simple:
> 
>   * Open Sound settings app.
>   * Edit name of sound device to reflect my configs.
>   * See the device thusly described thence-forth in the Sound settings
>     app at least, ideally in any app of mixer that works with cards.
> 
> That's looking like a biggish sort of ask as I don't even suspect 
> device.description is the right place for it, as that is populated with 
> something semi sensible already. Though it might be, as I'm not sure if 
> there's a pulaseaudio spec that states that card.device.description 
> should be used to identifying cards in apps that work with them.

device.description is what all friendly UIs should use to label the
card.

> It might rather be that the most appropriate path forward is a new 
> property like card.device.name that is editable and has methods for 
> setting it and remembering it. But that actually raises the question, 
> whether such a property belongs in pulseaudio at all or in alsa?

It could be argued that this belongs in alsa. However, the current
state of things is that alsa doesn't provide very user-friendly card
descriptions, and I don't think it has an API for doing runtime
modifications either.

The way pulseaudio generates descriptions is convoluted, but I think
most USB cards get their description from udev's ID_MODEL_FROM_DATABASE
property.

By the way, I now noticed that it's possible to directly affect the
card description by setting SOUND_DESCRIPTION in udev configuration.
This of course is not usable for the "set description in sound settings
UI" use case.

> Or I note that ports sometimes have a device.product.name property, 
> which if it's an HDMI or DisplayPort device seems to contain a lucid 
> name for the device. Perhaps support for a port property like 
> device.description is consistent with the paradigm in place, and it 
> could be made editable/updatable and then Sounds Settings apps can use 
> this in their titles for sound devices?

Hmm... We indeed read the HDMI monitor name and store it in the port's
device.product.name property. I believe the purpose of this is to use
that as the UI label for the port, but it looks like the code that
reads the monitor name only sets the device.product.name property and
doesn't update the port description. I don't know if there are UIs that
show the product name in place of the normal description. In any case,
not setting the port description looks like a bug.

This is not really related to card descriptions. If a UI shows a list
of cards, it should use the card description, and if it shows a list of
ports, it should use the port description.

And yes, it would be good to have the port descriptions user-editable
as well as the card descriptions.

> My experience is not deep. I'm dishing for wisdom.
> 
> Either way I see this is likely a common use case among people working 
> much with sound, and a real bother.  Printers don't have this problem, I 
> can name them. Awesome. And the name is distinct form the description.

Regarding the separation between a name and a description, it's unclear
to me how you would like those to be handled. We already have a name
for reliable and persistent identification, and a description for user-
friendly labeling. You mentioned that you'd like to change the name on
the fly as well, but your example use case was about changing the user-
friendly label in sound settings. Why would you want to change the
name? While it would be nice to be able to change the ugly names to
something easier to remember, implementing that would be much more
complicated than implementing support for editable descriptions.

-- 
Tanu