My reply got a lot longer than I originally planned to write.
TL;DR - Having the software working is just the tip of the iceberg. The
other 9/10ths needs to be a concentrated effort on documentation and
driving adoption of the new API and not relying on the compatibility
layer. Otherwise it will be destined to become the next wayland (12
years on and I'm still having to make custom hacks/changes in my browser
just to do screen sharing).
On 20/11/2020 16:26, Ben Cotton wrote:
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.
I think this is a great idea.
I am not an audiophile or a desktop developer (yet) and I have only had
F33 on this system for a little over two weeks. However, I have been
running Ubuntu full time since 2016 (and on/off for the last 20 years) -
so I have experience with GNOME and pulseaudio as an "average user".
A lot of the comments against this idea seem to stem from the
perspective of stability (or lack of it, to be more precise). That there
is quite some way to go before its a replacement for pulseaudio. Which
sounds like a fair argument except for one important fact...
pulseaudio is not perfect. Far from it!
I've lost count of the number of times my chosen input device changes
between boots, or the volume control just stops working, or no matter
how many times I quick and relaunch settings or logout/login the
settings panel refuses to obey my selection.
Yes. You could argue that the fault lies with GNOME Settings, or any of
the other applications that have shown problems in the past. However, if
an API makes it that difficult to be able to program against it
reliably, then I would argue that the API is broken.
I would be inclined to worry less about stability (or even
compatibility) at this point and focus on making sure that there is a
well thought about API that can genuinely provide Linux desktop audio
for the next 10 years. And make sure that API is extremely well
documented so application developers can make the switch to the new API
as easily as possible.
Today, even some of the biggest software projects have very rapid
development cycles compared to what they were a few years ago. Java for
example [1]. So any active software should be able to switch to the new
API within a few development cycles. The compatibility layer should be a
short-term convenience and not a long term back-stop.
Bugs can be fixed relatively easily and quickly. Logical or functional
changes to an API not so much.
If this is already the case, then to really have this available as a
default option for F34, then documentation needs to have a serious
update within the next few weeks. As others have mentioned, there seems
to be confusion as to what exactly are the steps involved in testing
this out under F33.
I started on the docs page [2] about an hour ago and am still non the
wiser as to what I would have to do to test.
There should also be a clear roadmap specifying key dates / releases.
For example:-
- Available for testing from F33 onwards.
- Default in F34 with compatibility library.
- Active support/development of the compatibility library ends with F36.
It would also be worth investigating what would be involved in getting
some key software switched over to the new API by way of a showcase.
[1] https://adoptopenjdk.net/support.html
[2] https://pipewire.org/#documentation
_______________________________________________
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
