[pulseaudio-discuss] RFC: loopback manager

[Alexander E. Patrakov]

сб, 25 мая 2019 г. в 18:38, Tanu Kaskinen <tanuk at iki.fi>:
>
> Hello,
>
> I nowadays use module-loopback on a daily basis, and I thought it would
> be nice to provide a GUI (in pavucontrol) for configuring loopbacks.
> For this I propose we create a new module: module-loopback-manager. The
> purpose of that module is to provide a client interface for managing
> loopbacks. Without such manager interface it's not possible to create
> loopbacks that stay around after reboot. Well, one could add module-
> loopback to default.pa, but that doesn't mesh well with dynamic
> hardware, and that's not doable from pavucontrol anyway. The new module
> would maintain a database of loopbacks, so that they can be recreated
> after a reboot.
>
> The client interface would contain functionality for adding and
> removing loopbacks, and changing the parameters of existing loopbacks.
>
> A loopback object would have the following attributes (to be shown in
> "pactl list loopbacks"):
>
>     Name: The identifier for the loopback.
>
>     Description: A human-friendly description for UI labels.
>
>     Source: The source name. Can also be unset, in which case the
> loopback should follow the default source setting.
>
>     Sink: The sink name. Can also be unset, in which case the loopback
> should follow the default sink setting.
>
>     Enabled: The user can temporarily disable a loopback without
> removing it altogether.
>
>     Running: A boolean that is true when the loopback is running, and
> false when the loopback is stopped for whatever reason. The interface
> should also provide a human-friendly string explaining why the loopback
> is not running (the loopback could be disabled, the sink or source
> might not be present at the moment, or the sink or source might be
> suspended).
>
>     Requested latency: The latency that has been requested by the user.
>
>     Current latency: The current actual latency. Might be different
> than the requested latency, because the requested latency may be too
> low to work.
>
>     Persistent: A boolean indicating whether the loopback will be
> restored after restarting PulseAudio. My plan is that loopbacks that
> are created through the manager interface are always persistent, and
> non-persistent loopbacks are only for loopbacks that are created by
> loading module-loopback.
>
>     Source output index: When the loopback is running, it will have a
> source output associated with it.
>
>     Sink input index: When the loopback is running, it will have a sink
> input associated with it.
>
>     module-loopback index: When the loopback was created by loading
> module-loopback, this is the module index.
>
> A maximum latency attribute could be added later, which would prevent
> the loopback increasing the latency too much (at the cost of drop-
> outs).
>
> The pactl interface could look like this:
>
> pactl loopback add [--description=<description>] [--enabled=<enabled>] [--latency-msec=<latency>] <name> <source> <sink>
> pactl loopback remove <name>
> pactl loopback set-description <name> <description>
> pactl loopback set-source <name> <source>
> pactl loopback set-sink <name> <sink>
> pactl loopback set-enabled <name> <enabled>/toggle
> pactl loopback set-latency-msec <name> <latency>
>
> Any thoughts? Would this kind of addition be welcome? If you think that
> it's not worth having this feature, please say so, so that I don't
> spend too much effort on this.

I think it would be a useful exercise for you as a developer, even if
there are very few users. At least, it is (AFAIK) the first attempt in
PulseAudio to create something dynamically based on a policy stored in
a persistent database. The experience gained through the exercise
would likely be useful in other cases when one needs to deal with the
"default.pa is too static and cannot configure hot-plugged things"
problem.

An obvious proposed addition to the API would be an ability to list
persistent loopbacks, including those that refer to a source or a sink
that doesn't exist at the moment.

-- 
Alexander E. Patrakov