Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux