[pulseaudio-discuss] RFC: loopback manager

[Joe]

On 5/26/19 1:43 AM, Alexander E. Patrakov wrote:
> сб, 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.
>
I don't pretend to understand loopbacks at all (I'm an end user,
primarily long time lurking here to see what I can learn) but, based on
Alexander's comment:

Something I'd really like (eventually) is a "profile switcher" of some
sort where I could tell it (in a GUI or in a config file) something like:

"When I plug in HDMI monitor A, the sound should go to it (and the video
should be setup a particular way - outside the scope of this project)."

"When I plug in HDMI monitor B, the sound should come out of my computer
(because that monitor has no speakers) (and the video ...)"

As of now, I have to go into my KDE System Settings every time I switch
monitors and separately adjust the sound and video settings (although
kscreen is way better than it used to be). That facility is very nice
and does just about everything I want, but it's all manual. I would like
to be able to set it all up once for each device, give it a profile name
and just tell it which profile to use with all the settings set at once.
In an ideal world (one where I knew more than once sentence about what
dbus is ;)  ), it would be great to have rules to do this automatically.

While I know that most of this is beyond the scope of pulseaudio itself,
anything you can do to add the APIs or whatever else would be needed to
make this possible would be really appreciated. It sounds like this
current project might be a step in that direction.

Unrelated:

I have been lurking on this list for a long time. I am extremely
impressed with the support this project has from so many able
developers. The biggest thing I see is how well you all get along and
work out new ideas and proposals. You have plenty of disagreements, but
they are all civil - friendly most of the time - and things continually
get resolved and implemented.

I just wanted to let you know that "social" component of this project is
as impressive as the product itself.

Joe