On Tue, Nov 24, 2020 at 2:07 PM Joël Krähemann <jkraehemann@xxxxxxxxx> wrote: > > Hi, > > This is bad. > > On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann <jkraehemann@xxxxxxxxx> wrote: > > > > > > Hi all, > > > > > > For short, NO! I want to be able to shutdown pipewire in order to get instant > > > ALSA access. > > > > > > This was a real pain until pulseaudio recognized what they need to do: > > > > > > systemctl --user stop pulseaudio > > > systemctl --user stop pulseaudio.socket > > > killall pulseaudio > > > > > > If you want real low latency you won't do any additional layer on top of > > > ALSA. > > > > > > Further, my application provides some functional integration tests. > > > > > > http://nongnu.org/gsequencer > > > > > > just run: > > > > > > ./configure --enable-run-functional-tests > > > make > > > make check > > > > > > Alternatively you can run against installed libraries: > > > > > > ./configure --prefix=/usr --enable-run-functional-tests > > > make > > > make ags-integration-functional-test > > > > > > Or to run in parallel using xvfb-run: > > > > > > ./configure --prefix=/usr --enable-run-functional-tests > > > make > > > make ags-parallel-integration-functional-test > > > > > > Didn't look at pipewire, yet. Finally, please consider to shutdown the > > > process completely as desired. > > > > > > > We already have to have PipeWire running in GNOME and Plasma for > > Wayland sessions, so we can't completely shut it off. However, the > > pipewire-pulseaudio package provides a separate set of PulseAudio > > services with the same unit names as the ones provided by the > > pulseaudio package. Shutting those down would have the same effect for > > you. > > Well I used to `dnf remove pulseaudio` might be I have to `dnf remove pipewire`, > then. > Sorry, no. Doing that will cause the desktop environment to get uninstalled. We rely on PipeWire for handling mediation of A/V resources across domains, including for handling screensharing and screencasting. Removal of the pipewire-pulseaudio package will remain possible, but you'll still likely cause problems because the desktops *expect* this stuff to exist and stuff that requires a PulseAudio daemon will be broken if none exist. > > > > That being said, I have spoken to a few audio engineers, and basically > > none of them use ALSA directly. They can't because ALSA doesn't > > support mixing properly, among other things. Most of them use JACK or > > PulseAudio, depending on their requirements. PipeWire is intended to > > simplify the pro audio case while bringing those benefits to casual > > audiophiles who use PulseAudio. > > I really doubt that you listen to youtube while creating music. What do > you want to mix? Might be for some exotic JACK setup. > You never really know. I would be hesitant to presume such things, given the folks I've talked to. At least one of them does in fact do YouTube stuff while doing audio and video production, because that's his job. For him, the PipeWire setup this Change proposes will make his life easier. I expect other pro audio types to be similarly happy about these improvements. And note, the lead developer of Fedora Jam (a spin dedicated to pro audio) has signed off on this Change. In fact, he was the primary driver for us to work toward making this Change proposal in the first place. I am working with Wim (the change proposer), the Workstation WG, and the KDE SIG to make the necessary adjustments in Rawhide to support swapping between PulseAudio and PipeWire. So far, Wim has not been interested in backporting the fixes I've made to Fedora 33, so the plan would be to start producing media with PipeWire on it for Rawhide and set up multiple events over the next few months to get things tested. Richard Brown from openSUSE also informed me that it's technically possible to do some level of audio subsystem QA using OpenQA, but I'm not sure how to do it. Perhaps that's another avenue we can pursue to improve integration testing coverage? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
