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
