On ke, 25 marras 2020, Wim Taymans wrote:
Hi all,
First of all, thanks for the comments, keep them coming. We have seen
these concerns many times before with big infrastructure changes like
pulseaudio or wayland or systemd. I think they are necessary to keep
our feet on the ground and not get carried away by our pipe dreams (pun
intended).
As the author of PipeWire and creator of this Change proposal, I will
try to address some of the concerns I see here in the comments:
It needs more testing...
This change request is about enabling PipeWire audio by default *for
testing* in a testing environment. I'm proposing this because I think
it is ready for *testing*. I hear some claims that it is too early to
test; as the main developer, I disagree. It's not too early to test.
People have been running PipeWire as the main audio backend for some
time now, and so can you.
The goal when enabling this by default is to have a nicely integrated
solution that people can try, test and revert. This will give us more
testers and feedback and bring us closer to the final goal.
but I can't even enable it to test! packages don't install and have conflicts!
We're working on getting the dependencies right on other packages so
that we can actually swap implementation.
Should we have waited until this works better? perhaps.
We ask for some patience until this is fixed, I expect this to be
testable next week. Stay tuned for an update.
This is going to be so buggy, why do this to us
The feedback from early testers give me confidence that it will not be
all doom. There will be bugs, they will get fixed and you'll have to
retest. It is how to move forward.
By the end of the testing and the beta freeze we end up with a nice
list of bugs and must-have features that people found (or not) and we
roll back (or not).
why bother, this will fail and we'll have to roll back anyway
I have no problem whatsoever with rolling back after an honest round of
testing. This proposal will be resubmitted for the next release and we
try again. But, this would be all pointless without taking the risk to
actually test the new things first.
it's still in active development
A project like this takes time to develop and will hopefully be in
active development for many more years. There are so many ideas
remaining...
Development of the video parts started in early 2017, more than 3 years
ago and ended up in fedora 27 as a dependency for screencasting.
Screencasting still does not work in Fedora 33. It pretends to work as
in claiming through the applications and GNOME indicators that the
screen / application window / browser tabs are shared but nothing gets
actually shared. Tested today with Firefox and Chrome on Wayland for
Google Meet, BlueJeans, Jitsi.
How can we make sure audio replacement doesn't end up in the same state?
Development and testing of the redesigned audio core started in june
2018 and ended up in Fedora 32. You could already test the audio on f32
and some people did.
The core audio parts and API/ABI has been stable since february 2020.
Since then we've been working on the use cases, management of devices
and streams and tools. We've had a crew of early testers and incredible
feedback.
I believe It's ready for more testing.
A traditional way to provide testing ground is to:
- make packages available on current Fedora release through COPR
repositories
- provide them in Rawhide
- provide means to switch to the proposed setup manually with somewhat
easy and documented set of steps
- provide pre-integrated image that defaults to the proposed setup
Enabling Pipewire Audio by default in Rawhide does not give any
indication things work because Fedora users aren't necessary using
Rawhide as their desktop environments.
Please consider at least providing COPR repository for Fedora 33 so that
it is easy to switch to PipeWire Audio on otherwise working desktop
system -- without the necessity to install a virtual environment with
Rawhide.
but the pulseaudio replacement server is only 5 weeks old!
It is and it works very nicely indeed, I want you to try it.
What's more impressive is that it does not take a lot of complicated code to
implement
this on top of PipeWire.
It's not ready, it needs to mature more, it's too early
This may be true but it's too early to make that decision without giving it a
round of
testing first, IMHO.
There are things that are not implemented yet but I think those are not
important enough
to block general testing.
Some thing might simply not be implemented either (like ESD compatibility) and
will
cause regressions. I want to know what's important for people, what are
must-haves.
there is not enough time to test
Perhaps not and then we need to roll back and test more in the next rawhide. It
should
not stop us from starting to test now, when the developers think it's ready for
testing.
I don't know how to measure when 'enough testing' has been done. It ultimately
depends
on how confident people feel after using it for a while.
I've tried it and it doesn't work
You have not tried what we propose for rawhide and f34 because there is no easy
way
to install this yet, please stay tuned. We're going to be fixing the
dependencies and
upgrading to the latest versions to make this easy.
Also please tell us what is wrong and please try again after a fix landed.
Much of the instability with browsers and music players got fixed after the
pulseaudio
replacement server was implemented.
but I don't want to test all this
This is ok, I can understand that you don't want to deal with possible audio
problems. You
will have to install pulseaudio again and opt out. You will have to hope that
other people
do sufficient testing. It is a bit strange when you are running rawhide, but
hey.
but this and that is broken, it's all pointless, why bother, you'll never get
this fixed in time
Maybe so. Please let us know what's broken. It might be an easy fix and we can
retest
an updated version. Or not, and then it's a blocker and we roll back. But you
have to let
us know.
So my proposal still is:
* Make it easy to swap, hopefully get that working smoothly next week. stay
tuned.
* Enable by default in rawhide
* fix bugs, repeat, retest..
* collect final experiences at beta freeze, re-evaluate rollback or not
Is this something we can agree on?
Wim
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
