| Summary: | media-video/pipewire-0.3.25 pulls ALSA plugin unconditionally | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ostashevskyi Viktor <ostash> |
| Component: | Current packages | Assignee: | Sam James <sam> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | asturm, gentoo, ionen, leio |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/gentoo/gentoo/pull/19965#pullrequestreview-635256091 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
As I explained on the merged GitHub PR - disabling both plugins would break any application that tried to use the ALSA API. I do not believe that producing known broken setups is a good thing to do, so I think requiring a working ALSA fallback is the right approach for people looking to migrate to PipeWire. Surely Gentoo does not want to repeat the infamous Ubuntu's PulseAudio migration (which was, I think, at least in part their omission or misconfiguration of the ALSA plugin). Furthermore there already is such a USE flag, namely pipewire-alsa - introducing another one would be QA violation, since USE flags must work on the build system. (In reply to Niklāvs Koļesņikovs from comment #1) > As I explained on the merged GitHub PR - disabling both plugins would break > any application that tried to use the ALSA API. I do not believe that > producing known broken setups is a good thing to do, so I think requiring a > working ALSA fallback is the right approach for people looking to migrate to > PipeWire. But current stable media-sound/pulseaudio allows to do that, and this doesn't look to be a problem. Most users emerge it together with its plugin for ALSA, but some don't, and I'm one of such users. I don't have any software that uses ALSA directly and have 'alsa' USE flag disabled completely. Why do I need any plugins for ALSA? > Surely Gentoo does not want to repeat the infamous Ubuntu's PulseAudio > migration (which was, I think, at least in part their omission or > misconfiguration of the ALSA plugin). PulseAudio is already in Gentoo for years, it has USE flag for disabling ALSA plugin for years, everything is working fine for years, nobody is hurt by having it. All I'm asking about: allow PipeWire to configured in a similar way as existing PulseAudio. > Furthermore, there already is such a > USE flag, namely pipewire-alsa - introducing another one would be QA > violation, since USE flags must work on the build system. Can you elaborate a bit more about it? What will be wrong to replicate the existing 'alsa-plugin' USE flag from media-sound/pulseaudio to media-video/pipewire? It is quite a common pattern in Gentoo ebuilds, that one USE flag enables some functionality (in this case 'alsa-plugin' for having a plugin), and another flag selects specific implementation (in this case 'pipewire-alsa' for selecting between plugin from PipeWire vs PulseAudio). There's the very long bug 519530 which details why and how media-sound/pulseaudio got it's Gentoo rules violating alsa-plugin USE flag. I do not indent to let that happen to media-video/pipewire, and I'm quite sure all/most developers who contribute to the pipewire ebuild feel the same way. ;) (In reply to Niklāvs Koļesņikovs from comment #3) > There's the very long bug 519530 which details why and how > media-sound/pulseaudio got it's Gentoo rules violating alsa-plugin USE flag. > I do not indent to let that happen to media-video/pipewire, and I'm quite > sure all/most developers who contribute to the pipewire ebuild feel the same > way. ;) To be honest, I still do not get it. The bug you've referenced was resolved by adding alsa-plugin USE flag to media-sound/pulseaudio. Everyone got happy, QA approved. This is the same I'd like to have for media-video/pipewire. I'm not very familiar with Gentoo QA policy, so if there is other way to achieve desired behavior (do not install unneeded ALSA plugin), i.e. have single alsa-plugin USE flag in media-video/pipewire which pulls some virtual/alsa-plugin, or something else - I'm totally fine :) A Gentoo developer will answer and presumably deal with this bug later but for now here's my understanding of their response to this bug: # echo media-plugins/alsa-plugins-1.2.2 >> /etc/portage/profile/package.provided I hope this helps you and whoever else is afflicted by this bug. I realized this bug just now, because only a few days ago the broken ebuild got stable. (In reply to Niklāvs Koļesņikovs from comment #3) > There's the very long bug 519530 which details why and how media-sound/pulseaudio got it's Gentoo rules violating alsa-plugin USE flag IMHO, the bug was there in the first place, because the original ebuild did not give the user sufficient choice for the setup. And when finally it was fixed, this fixing became a bit of a problem, because the existing broken default of forcing the plugin has changed, and some feared that users might be surprised by the change. And it turned out in the further discussion of the bug that even this is considered to be the lesser argument compared to taking away the user's choice. The reasons why some users want this choice are the same as for pulseaudio: Sometimes they want to use pipewire (e.g. for certain applications like discord, or when they want to stream to bluetooth), and sometimes they don't. Note that, for instance with mplayer there are the options -ao pulse and -ao alsa which becomes a non-option with the plugin. > I do not indent to let that happen to media-video/pipewire, Then do not repeat the mistake of the first pulse-audio ebuilds to force some behavior which should be the user's choice. It is not too late for this: The current ebuild which does not force anything was stable until a few days ago. Just introduce a USE-flag for the choice now. If you want to strongly encourage using the flag, then either default-enable it or negate its meaning (USE=minimal or USE=minumal-plugins). (In reply to Niklāvs Koļesņikovs from comment #5) > echo media-plugins/alsa-plugins-1.2.2 >> /etc/portage/profile/package.provided That's a hack and not a solution. It is not even a working hack if you want other alsa-plugins. Unfortunately, currently the only "working" hack to fix this problem is to fix the ebuild in the local overlay. Nice opinions that I do agree with but reality stands in your way. ;) The problem is not having a USE flag per se - the problem is that Gentoo prohibits USE flags that do not change build output such as config files. Pre-made ALSA Lisp scripts (with .conf extension no less) do not count as build output and therefore cannot be controlled by dedicated USE flags. There's of course a catch - the reverse is possible - if you have a valid USE flag, it can also control installation of non-build files, too, which is a loophole that the ebuild already uses. The whole point of the previously referenced PulseAudio bug which people seem to ignore en masse is that it was not easy to get that alsa-plugin IUSE added to the ebuild, nor was it something that was done by the regular package maintainer. And the details with PipeWire are sufficiently different, that such ISUE should not be added. Can PipeWire do better? Yes! But not in a way that you think - PipeWire gives up ALSA devices it's not using (unlike PulseAudio), so it's always possible to for an ALSA application to take over a device so long as it explicitly opens a hardware interface rather than the default device which is routed to PipeWire. Speaking of which, that's the purpose of the plugins both from PulseAudio and PipeWire - they establish a pipewire or pulseaudio device and then set the default ALSA device to be that. Technically that's two ALSA plugins, by the way, but who noticed that before I told them? Which is why this level of complexity is best abstracted away, since it requires a lot of knowledge to make minute and insignificant decisions. Why are they insignificant? Because PipeWire and PulseAudio need an appropriate plugin installed or any ALSA application will wreak havoc out of the box, which many users will blame on anything but the distro, which made such broken config the out of the box experience. So a plugin needs to be present when using PipeWire or PulseAudio, however it makes little sense to remove the plugin temporarily just to let a single app take control of hardware, since the same can be achieved by either stopping PulseAudio or in case of PipeWire by simply not using that device, and in both cases telling the particular ALSA application to use an ALSA device corresponding to particular hardware rather than default. I tested this with mpv --ao=alsa --audio-device=alsa/hw:0 which is able to output to that device with the full PipeWire stack running, provided that the device wasn't in use at the time. It should be pointed out that at least right now PipeWire will not be happy if it tries to open a device and fails because some application has taken an exclusive control over it and may require daemon restart to make it use that device again, so use this carefully, if at all. Finally your claim about package.provided being a hack is wrong - the ebuild blocks specifically media-plugins/alsa-plugins[-pulseaudio], so having that package installed with some other plugins installed but pulseaudio plugin disabled is valid. It's even the default dependency with !media-plugins/alsa-plugins being the alternative, just to make it extra sure that Portage won't get confused and try removing alsa-plugins when user has that installed for other plugins (however unlikely such use cases might be). My late reply is not a sign of agreement but simply means that somehow I missed your reply... > The problem is that Gentoo prohibits USE flags that do not change build output such as config files The main purpose of the USE-flag would not be a change of the config file but a change of a dependency. And those are certainly acceptable by gentoo policy, for otherwise several hundred packages would violate this policy as a quick eix -vl |grep 'PDEPEND.*[?]' shows. (Yes, not all of these are matches, but most of them, e.g. with USE-flags manpager, examples, branding, themes, contrib, vim-syntax, emacs,...) Moreover, all USE-flags of virtuals are counterexamples. I understand the motivation for this: If you have a huge package, you do not want to force recompilation for nothing. But pipewire is not a huge package. Of course, we would not need to have this discussion if we would have runtime-switchable USE-flags, but clearly this is out-of-scope of this bug and will not happen in the near future. > PipeWire and PulseAudio need an appropriate plugin installed or any ALSA application will wreak havoc out of the box I would call it *working* out-of-the box if the program with alsa output indeed outputs directly to alsa and can be controlled with alsa-mixer etc instead of wrapping over a tool which has normally nothing lost in that context, takes a delay, and sometimes has problems. Moreover, alsa users are normally aware about problems of two simultaneous programs with sound output. Anyway, I will not argue which configuration is better or more intuitive for which user - this is up to the user to decide. The problem is that you are taking away the user's choice and push "the only true config" down the user's throat unless they maintain the ebuild in their local overlay. To make it clear: I am not arguing against any defaults or maybe even use.force (or use.mask if you go for a negated USE-flag like "minimal"). These are valid means to convince the user about the configuration you want to suggest. But I am arguing against forcing the user to maintain their own ebuild if they do not agree with that configuration for whatever reason. > Finally your claim about package.provided being a hack is wrong No, what I said is completely right: If you want to have *no* alsa-plugin for pipewire and pulseaudio (as is the whole point of the discussion we have), you are *not* able to install media-plugins/alsa-plugins[-pulseaudio]: In order to avoid using the pipewire plugin in this situation you *must* have installed media-video/pipewire[-alsa-plugins], and this in turn forces the dependency media-plugins/alsa-plugins[pulseaudio]. I think this is essentially covered by sound-server and the other changes we've made since. |
When using media-sound/pulseaudio I have a choice whether I want to install a PulseAudio plugin for ALSA or not via alsa-plugin USE flag. When using media-video/pipewire such plugins is installed unconditionally, you can only select whether this will a native PipeWire plugin or PulseAudion one via pipewire-alsa USE flag. media-video/pipewire shouldn't force the installation of ALSA plugin, this should be controllable via USE flag, i.e.: REQUIRED_USE = " pipewire-alsa ? ( alsa-plugin ) " RDEPEND = " alsa-plugin ? ( pipewire-alsa ? ( media-plugins/alsa-plugins[-pulseaudio] ) !pipewire-alsa? ( media-plugins/alsa-plugins[pulseaudio] ) ) " Reproducible: Always