On Sun, 2019-05-26 at 20:07 -0400, Joe wrote: > On 5/26/19 1:43 AM, Alexander E. Patrakov wrote: > > сб, 25 мая 2019 г. в 18:38, Tanu Kaskinen <tanuk@xxxxxx>: > > > 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. I don't use KDE myself, so I'm not super familiar with its UI. It sounds like you have to set multiple things to switch all audio from the internal sound card to the monitor or vice versa. Are there multiple audio categories that all need to be changed? In Gnome there's just one output selection. To support the two monitors case we would have to do routing based on the monitor name, and it's not quite clear how to fit that into the current routing model. HDMI monitor handling has been discussed before, but I don't remember what (if any) were the conclusions. My current thinking is that the ALSA backend code in PulseAudio should add the monitor name to the HDMI sink name, so different monitors would appear as separate sinks. Currently there's one sink per HDMI connector, so all monitors connected to that connector are treated the same. With separate sinks for the monitors you could just set the monitor with speakers the default sink, so it would automatically get used when present, and otherwise the internal sound card would be used. This is just throwing ideas around, I don't currently have time to do the implementation work. > 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. This loopback manager project isn't really relevant to what you want to achieve, unfortunately. > 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. As a maintainer, I guess I'm in a position to say "thanks"! For me the problematic areas of the project tend to be more in my mind, so it's nice to be reminded that an unfriendly community isn't one of those problems! -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
