<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks Tanu, your observations are
      every very helpful and time saving. <br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      The use-case I'm after is simple:<br>
      <ul>
        <li>Open Sound settings app. </li>
        <li>Edit name of sound device to reflect my configs.</li>
        <li>See the device thusly described thence-forth in the Sound
          settings app at least, ideally in any app of mixer that works
          with cards.</li>
      </ul>
      <p>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. <br>
      </p>
      <p>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?</p>
      <p>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?<br>
      </p>
      <p>My experience is not deep. I'm dishing for wisdom. <br>
      </p>
      <p>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. <br>
      </p>
      <p>Regards,</p>
      <p>Bernd.<br>
      </p>
      <p><br>
      </p>
      Tanu Kaskinen wrote:<br>
    </div>
    <blockquote cite="mid:1471270140.1263.17.camel@iki.fi" type="cite">
      <pre wrap="">On Mon, 2016-08-15 at 23:28 +1000, Bernd Wechner wrote:
> I notice it's possible to alter sink properties with 
> update-sink-properties but see no analog for card properties.

> Specifically I find that pulse audio sets the device.description for 
> cards, to "Built-in Audio" if it's on the motherboard, but for USB sound 
> devices takes the USB property idProduct.

> Either way I use lots of sound devices and they are apparently listed by 
> card device.description in the Sound settings app (Linux Mint Cinnamon) 
> and I'd like to be able to adjust the device.description for cards.

> Is there a way to do this I'm not seeing?

I don't think there's any way for cards that are loaded by module-udev-
detect. If you disable module-udev-detect and load module-alsa-card
instances manually, then you can use the card_properties argument.

Patches for adding a set-card-description command for pactl (and to the
native protocol) would be welcome. I don't like the idea of adding a
more general "update-card-properties" command, however. The server uses
proplists for things that clients shouldn't be able to freely mess
with. If "update-card-properties" would be added, we would have to make
sure that the server doesn't trust the proplist values too much.

pacmd already has the update-sink-properties and other similar
commands, which may seem strange given what I wrote above, and indeed I
wish those commands didn't exist. It could be argued that not much
extra damage would be made by adding an update-card-properties command
to pacmd, and that might be true (I might even accept such patch), but
given that pacmd is semi-deprecated in favour of pactl, I'm not really
enthusiastic about adding new functionality to pacmd.

-- 
Tanu
_______________________________________________
pulseaudio-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pulseaudio-discuss@lists.freedesktop.org">pulseaudio-discuss@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss">https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>