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

[Tanu Kaskinen]

On Thu, 2016-08-18 at 08:41 +1000, Bernd Wechner wrote:
> c) at the pulseaudio level there are already description properties 
> available (on sinks, cards and ports) and all it would take to allow 
> tweaking them is an interface of sorts (update-sink-description, 
> update-card-description, update-port-description?). Not sure if these 
> stored descriptions survive the unplug, plug scenario mind or if they 
> are overwritten when replugged.

What's missing is an API in libpulse to set the descriptions,
modification to the native protocol to pass the "set description"
commands from the client to the server, and saving and restoring the
descriptions in module-device-restore (for sink and source
descriptions) and module-card-restore (for card and port descriptions).
Dealing with hotplugging is not a problem, those modules already
restore other things in a way that works in hotplugging use cases.

By the way, we actually already support changing sink and source
descriptions (so just card and port handling is missing). It's
implemented by module-device-manager, but that module is not loaded by
default, and the client API works only when the module is loaded. I'd
like to move the description management out of module-device-manager.

> It seems to me that on MINT at least the Sound settings and the System 
> tray sound app list output devices differently (superficially it looks 
> like one lists ports the other sinks).
> 
> Either way, I'm curious if pulse publishes a document or spec which 
> stipulates what the expected (planned for) manner of describing sinks, 
> cards and ports in apps is, in order to promote consistency?

I don't think there's such document.

Listing ports would be more user-friendly, but it's simpler to
implement a thing that lists just the currently available sinks.
Originally pulseaudio only had sinks and sources; cards and ports are a
later invention, and maybe partly for that reason sinks and sources
tend to be emphasized a bit too much in UIs (and also in the libpulse
API).

-- 
Tanu