Re: Policy: should libraries depend on services (daemons) that they can speak to?
Hi, Le dim. 7 janv. 2024 à 20:40, Ansgar a écrit : > > 1. libpulse0 & friends > -- > > libpulse0 is a client library for the Pulseaudio server. It doesn't do > much without pulseaudio. > > Q: Should libpulse0 have Depends: pulseaudio? Please don't do that. At least one pipewire module depends on libpulse0 (libpipewire-module-pulse-tunnel from the libpipewire-0.3-modules package). But, pulseaudio is useless in this case that means it will be unnecessarily pulled. Best regards, Dylan
Bug#1056701: ITP: roc-toolkit -- real-time audio streaming over the network
Package: wnpp Severity: wishlist Owner: Dylan Aïssi X-Debbugs-Cc: debian-devel@lists.debian.org, debian-multime...@lists.debian.org * Package name: roc-toolkit * URL: https://roc-streaming.org/ * License: MPL-2.0 Roc is a network transport, highly specialized for the real-time streaming use case. The user writes the stream to the one end and reads it from another end, and Roc deals with all the complexity of the task of delivering data in time and with no loss. Encoding, decoding, adjusting rates, restoring losses - all these are performed transparently under the hood. This package is maintained by Debian Multimedia Team at: https://salsa.debian.org/multimedia-team/roc-toolkit
Bug#1031002: ITP: libavtp -- Audio Video Transport Protocol (AVTP)
Package: wnpp Severity: wishlist Owner: Dylan Aïssi X-Debbugs-Cc: debian-devel@lists.debian.org, debian-multime...@lists.debian.org * Package name: libavtp * URL: https://github.com/Avnu/libavtp * License: BSD-3-clause Audio Video Transport Protocol (AVTP) specified in IEEE 1722-2016 spec. Remark: This package is maintained by Debian Multimedia Team at: https://salsa.debian.org/multimedia-team/libavtp
Bug#1021532: ITP: liblc3 -- Low Complexity Communication Codec (LC3)
Package: wnpp Severity: wishlist Owner: Dylan Aïssi X-Debbugs-Cc: debian-devel@lists.debian.org, debian-multime...@lists.debian.org * Package name: liblc3 Version: 1.0.1 * URL : https://github.com/google/liblc3 * License : Apache-2.0 Description: Low Complexity Communication Codec LC3 is an efficient low latency audio codec. This codec is required to add Bluetooth LE Audio support to pipewire. Remark: This package is maintained by Debian Multimedia Team at: https://salsa.debian.org/multimedia-team/liblc3
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Hi Wouter, Le mer. 5 oct. 2022 à 09:21, Wouter Verhelst a écrit : > > I'm not familiar enough yet with pipewire to know which tools to use to > debug what went wrong. Can you point me to the relevant docs? Once I > have a better idea of what went wrong, expect a bug report coming your > way ;-) > You can find the upstream troubleshooting guide here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting I should add a paragraph about that on our wiki. In any case, feel free to open a "it doesn't work" bug against the pipewire package :-) Best, Dylan
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Le jeu. 15 sept. 2022 à 03:21, Ben Hutchings a écrit : > > I understand that applications with very low latency requirements may > need this sort of performance tweaking. But this is not the normal > case, and PulseAudio hasn't required this. If PipeWire does, I think > that's a serious limitation in PipeWire, and it is not ready for us to > make it the default. Le jeu. 15 sept. 2022 à 05:35, Felipe Sateler a écrit : > > This seems a step backwards to me. Even though pulseaudio also does the > same, the code in question is from an era before rtkit existed. Nowadays, > most users get their RT thread from rtkit. Why isn't rtkit enough for PW? By default, pipewire uses rtkit (without removing its safeguards) and it works perfectly without having choppy sound. In certain circumstances, we need to do some performance tweaking. Now, we have to find the right balance in the pipewire configuration to avoid playing with rtkit safeguards. I am not saying we should bypass rtkit (or remove its safeguards) by default, or even recommend our users to do it. But, if they have a particular use of pipewire requiring the upstream recommendations, we can probably help them and explain them what are the risks. Just a random example [1] where rtkit has limitation for some pipewire uses. rtkit was enough for pulseaudio, but because pipewire goes beyond pulseaudio support for real-time and low latency maybe that is no longer sufficient? But again, we are not talking about a normal use of pipewire. Dylan [1] https://github.com/heftig/rtkit/issues/25
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Le mar. 13 sept. 2022 à 19:25, Michael Biebl a écrit : > > Afaics, Dylan asked mostly if we should do the switch. He didn't give > any personal recommendation or preference. At least that's how I read > his initial email. I have a basic usage of pipewire, I only listen to music and make video calls with friends/colleagues. That is why I am not representative and cannot force the switch (although I will be happy if it happens). Hence my suggestion to get feedback from you. (Thanks for all of your replies!) We still have few packages depending/recommending/suggesting only on pulseaudio and not on either pulseaudio or pipewire-pulse [1]. I'll start tracking them and will propose a fix right now. This is even more important because the next pipewire-pulse package will be in conflict with the pulseaudio package to avoid fights between both servers [2] and because it is an upstream recommendation [3]. Currently, this is not a blocker since all the main packages already dep/rec/sug either pulseaudio or pipewire-pulse. The issue mentioned here regarding choppy audio in case of high CPU load and related rtkit errors messages, should be reduced with the next pkg version. As recommended by upstream [4], it will create a pipewire system group and set security limits [5]. The decision remains to users to add themselves in the pipewire group. Le mer. 14 sept. 2022 à 03:08, Felipe Sateler a écrit : > > Dylan, have you thought about how a transition plan would look like? Now, regarding the transition plan, I propose to switch right now to pipewire. This give us 4 months until the "transition and toolchain freeze" on 2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is also doing the switch) planned to be released on 2022-10-20 [7]. Thus, we will have 4 months for Debian and 2 months for Ubuntu to fix the worst bugs. Then, we will re-evaluate the situation here from the first of January, this will give us 2 weeks before the freeze to switch back to pulseaudio if we have too many unresolvable issues. Of course, this is not set in stone and we can still switch back to pulseaudio before January if we find pipewire is not ready for audio, but I am confident. I will continue to propose latest pipewire/wireplumber versions in bullseye-backports to get more feedback from users. Dylan [1] https://bugs.debian.org/992686 [2] https://bugs.debian.org/1013276 [3] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#should-i-uninstall-everything-pulseaudio [4] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#rlimits [5] https://bugs.debian.org/1011399 [6] https://release.debian.org/ [7] https://wiki.ubuntu.com/Releases
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Le ven. 9 sept. 2022 à 21:39, Michael Biebl a écrit : > > Should we repeat this mistake? Or put this differently: is there a > pressing need/compelling reason to switch to pipewire in bookworm? > I.e. what I miss from the proposal are the benefits of pipewire over > pulseaudio. > Can you elaborate why you'd want to make the switch in bookworm? Le lun. 12 sept. 2022 à 20:30, Jeremy Bicha a écrit : > > A brief explanation of the project and what it does can be found at > https://pipewire.org/ and more details are at > https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ These links and especially the second one reply to the questions what are the benefits of pipewire and why we should switch to pipewire. To summarize, pipewire is able to deal with a lower latency and with less CPU usage than pulseaudio. This improves video conferencing apps, like WebRTC in the browser. A very common practice these days. Using less CPU ressources is also something we should be careful even if in this case it is marginal. Pipewire improves the security by stopping applications from snooping on each other's audio. It also asks permission to Wayland or Flatpak to record audio (and video). PipeWire allows a finer control of applications are linked to devices and filters. Take a look at qpwgraph or helvum (the latter is not yet in Debian). PipeWire does not dictate policy management. It exposes nodes to be connected, but leaves the decisions on the connections to the policy manager. Currently, we have two policy managers in Debian: pipewire-media-session and wireplumber. Best, Dylan
Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Hi, I have been asked several times regarding when Debian will switch its default sound server from PulseAudio to PipeWire without having an official answer. Thus, I suppose it's the right time to start a discussion about that. As you know, PipeWire is already installed by default with Bullseye (at least with Wayland environments) for screen-sharing. PipeWire was not mature enough to use it as default sound server for Bullseye, but since it gained in stability, features and popularity. Several other major distributions (Fedora, Ubuntu is doing the switch with 22.10) have switched to PipeWire for audio [1-3]. We cannot talk about PipeWire without mentioning its session manager. Thus, this change should go along the switch of the default session manager, i.e. from the deprecated pipewire-media-session to WirePlumber. We still use pipewire-media-session as default session manager because it enables PipeWire *only* for screen-sharing and not for managing audio. Whereas WirePlumber always configures PipeWire for audio excepted by modifying conf files in a non-compatible packaging way. This issues was also hit on the Arch Linux side [4]. This WirePlumber behavior may be solved in the next major release 0.5 planned later this year. BTW, I just uploaded latest PipeWire and WirePlumber in bullseyes-backports (still in the NEW queue) to allow more users to test them. Best, Dylan [1] https://fedoraproject.org/wiki/Changes/DefaultPipeWire [2] https://fedoraproject.org/wiki/Changes/WirePlumber [3] https://wiki.ubuntu.com/ImpishIndri/ReleaseNotes [4] https://archlinux.org/news/undone-replacement-of-pipewire-media-session-with-wireplumber/
Re: use of Recommends by vlc to force users to use pipewire
Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard a écrit : > > a) pipewire package enables pipewire service by default Indeed, but pipewire service doesn't take control of audio over pulseaudio. Only pipewire-pulse does that. So, if you don't want to use pipewire for audio, then don't install pipewire-pulse and that's it. What is the real issue with pipewire service? libpipewire recommends pipewire for a reason [1], do you mean this is not a good reason? [1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1
Bug#993237: ITP: svt-av1 -- Scalable Video Technology for AV1
Package: wnpp Severity: wishlist Owner: Dylan Aïssi X-Debbugs-Cc: debian-devel@lists.debian.org, debian-multime...@lists.debian.org * Package name: svt-av1 Version: 0.8.7 * URL : https://gitlab.com/AOMediaCodec/SVT-AV1/ * License : BSD-2-clause Description: Scalable Video Technology for AV1 (SVT-AV1 Encoder and Decoder) The Scalable Video Technology for AV1 (SVT-AV1 Encoder and Decoder) is an AV1-compliant encoder/decoder library core. The SVT-AV1 encoder development is a work-in-progress targeting performance levels applicable to both VOD and Live encoding / transcoding video applications. The SVT-AV1 decoder implementation is targeting future codec research activities. Remark: This package is maintained by Debian Multimedia Team at https://salsa.debian.org/multimedia-team/svt-av1
