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

[Vasiliy Tolstov]

I'm using rpm-ostree based fedora system (fedora 33) with pipewire and
after latest update
pipewire-0.3.23-1.fc33.x86_64
pipewire-alsa-0.3.23-1.fc33.x86_64
pipewire-pulseaudio-0.3.23-1.fc33.x86_64
pipewire-utils-0.3.23-1.fc33.x86_64
pipewire-libs-0.3.23-1.fc33.x86_64
pipewire0.2-libs-0.2.7-4.fc33.x86_64
pipewire-gstreamer-0.3.23-1.fc33.x86_64

gnome can't output any sounds because output devices are empty.
alsamixer displays my sound card, but the default pipewire output is
empty.

сб, 20 февр. 2021 г. в 23:05, Brandon Nielsen :
>
> On 2/19/21 3:47 PM, Tom Seewald wrote:
> >> Well, the idea would be for us to put it into Rawhide and do a series
> >> of test days/weeks to get feedback and close any remaining gaps. If it
> >> doesn't manage to pull through by beta freeze, then we would revert
> >> and push it back to Fedora 35.
> >
> > Did these test days/weeks ever happen? I don't recall seeing an 
> > announcement or any talk about their results.
>
> Final preparations are happening now:
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/OZ62EIL7ZAS5HL6ZW7DE6TFE6EW7A2IA/
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Brandon Nielsen]

On 2/19/21 3:47 PM, Tom Seewald wrote:

Well, the idea would be for us to put it into Rawhide and do a series
of test days/weeks to get feedback and close any remaining gaps. If it
doesn't manage to pull through by beta freeze, then we would revert
and push it back to Fedora 35.


Did these test days/weeks ever happen? I don't recall seeing an announcement or 
any talk about their results.


Final preparations are happening now: 
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/OZ62EIL7ZAS5HL6ZW7DE6TFE6EW7A2IA/

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Tom Seewald]

> Well, the idea would be for us to put it into Rawhide and do a series
> of test days/weeks to get feedback and close any remaining gaps. If it
> doesn't manage to pull through by beta freeze, then we would revert
> and push it back to Fedora 35.

Did these test days/weeks ever happen? I don't recall seeing an announcement or 
any talk about their results.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Dridi Boukelmoune]

> The f33 xfce4-pulseaudio-plugin package from updates-testing can now
> work with pipewire and so far so good. I'm of course lacking the features
> I was using with paprefs, but will try to find in the pipewire docs whether
> the same can be achieved with pipewire-specific tooling.
>
> My main case was the "simultaneous output devices" to not have to do
> anything when I switch between bluetooth devices (plural) or physical
> jack output.
>
> Not sure when I'll get a chance to try Ardour, I haven't used it in months.

I wish I could have answered earlier but sharing my feedback now is
better than never.

I'd like to state first that while I enjoy pulseaudio without being
very knowledgeable or proficient, I'm also very enthusiast about
pipewire. I'm however feeling very uneasy with pipewire replacing
pulesaudio by default. At least from my experience on the Xfce spin.

First, I had to reboot my laptop to formally switch to pipewire, which
was not needed to switch back to pulseaudio. I'm not ruling out pebcak
on this specific point.

Then I started using pipewire and pavucontrol to switch between
devices, adjust volume for certain applications, configure devices. I
have some problems with pulseaudio where some applications like
firefox won't remember the volume I set them at (or maybe firefox
forces a 100% volume whenever it starts an audio server?) and some
applications like firefox will have their audio delayed the longer a
video meeting lasts and some applications refuse to have their output
changed (not firefox for that matter) for example via pavucontrol.

With pipewire it was stated in the change description that not all of
the features of the pulseaudio daemon were supported, and it was
visible. I was unable to select an output device for a running
application, any application. I would have to set the device I wanted
as the default one and it would only take effect for future playbacks.
With bluetooth devices in particular I was not always able to switch
between profiles.

Finally, one day after saying "so far so good" the pipewire-pulse
daemon started failing. I tried to dig the following logs from
journalctl but the interesting stuff seems to be gone already.
Restarting the daemon didn't help, which never happened to me with
pulseaudio. The pulseaudio daemon may fail me a couple times a year,
but a restart of the service always solved the immediate problem.

I used pipewire-pulse mainly with Firefox, Pragha and VLC (from
rpmfusion). VCL didn't work at all, I had to switch its audio to ALSA
to get sound. Everything else worked, modulus the problems mentioned
above like changing outputs etc.

In terms of devices I used built-in speakers, didn't think about
trying built-in jack, but used the built-in microphone. I also had
bluetooth devices in A2DP and HSP/HFP (including microphone) and a
USB microphone. No problems with the devices besides not being able
to route an application to or from a specific one without making it the
default.

Unfortunately I didn't have time to share my notes earlier, and no
time either to try to understand and possibly reproduce failures. So I
will keep an eye (and an ear) on piprewire but I would recommend
strongly against making it the default based on what I was able to
test. I would be happy to participate in a test day if (big if) I'm
available to follow troubleshooting and error reporting instructions
because my understanding is that this is a fast-moving project, but
I'm not confident it is ready to replace pulseaudio yet.

Maybe next time I'll get a chance to play with pulseaudio-jack too.

Dridi
___
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

Re: hotplug headphone detection in pipewire? (was: Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change))

[Tom Hughes via devel]

On 14/01/2021 11:45, Felix Schwarz wrote:

I switched a desktop F33 machine from pulseaudio to pipewire and it 
seems to work fine at a quick glance:


$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing 
--enablerepo=updates-testing

$ systemctl --user enable pipewire pipewire-pulse

Now I have the problem when I re-plug my headphones (old-fashioned 
headphone jack) that I don't see the headphones as output device via 
"pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...).


There's an upstream ticket that may be related:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/533

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

hotplug headphone detection in pipewire? (was: Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change))

[Felix Schwarz]

I switched a desktop F33 machine from pulseaudio to pipewire and it seems to 
work fine at a quick glance:


$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing 
--enablerepo=updates-testing

$ systemctl --user enable pipewire pipewire-pulse

Now I have the problem when I re-plug my headphones (old-fashioned headphone 
jack) that I don't see the headphones as output device via "pactl list sinks" 
(neither via pavucontrol, gnome's audio settings, ...).



However the low-level alsa tools can see the headphone jacks (e.g. "alsamixer") 
and I can use "aplay" to get sound output one the headphone jacks.


With pulseaudio I had the same situation but
$ pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect

fixed the situation for me (though I saw duplicated sinks via pulseaudio for the 
rest of the session).



-> Is there a way to force pipewire to rescan the available sinks? (Ideally 
there would be auto-detection of course)


I guess this is more a support question but I assumed that it might be on topic 
here as the main goal is to get some testing for pipewire in Fedora :-)


Felix
___
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

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

[Dridi Boukelmoune]

> Same explicit dependency with the xfce4-pulseaudio-plugin package.
>
> I'm now much closer to giving pipewire a try.

The f33 xfce4-pulseaudio-plugin package from updates-testing can now
work with pipewire and so far so good. I'm of course lacking the features
I was using with paprefs, but will try to find in the pipewire docs whether
the same can be achieved with pipewire-specific tooling.

My main case was the "simultaneous output devices" to not have to do
anything when I switch between bluetooth devices (plural) or physical
jack output.

Not sure when I'll get a chance to try Ardour, I haven't used it in months.

Cheers
___
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

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

[Dridi Boukelmoune]

> With the help of Tomas and Jan, we've got this sorted out. Upgrade to
> pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to
> share the screen. It doesn't help with UX of pipewire portal dialogs but
> this is something I can live with for time being.

Hi,

I noticed a pipewire update today and that greatly reduced the list of
dependent packages getting in the way of a dnf swap:

paprefs
pulseaudio-module-bluetooth-freeworld (rpmfusion)
pulseaudio-module-gconf
pulseaudio-module-gsettings
pulseaudio-module-x11
xfce4-pulseaudio-plugin

The paprefs package depends on pulseaudio-module-gsettings and is not
a problem, more like a collateral casualty.

The non-rpmfusion pulseaudio-module-* packages seem to be part of the
problem with an explicit pulseaudio dependency. They all come from the
pulseaudio SRPM, but it's not clear whether the scope of the
pipewire-pulseaudio package includes those modules. Playing a bit with
dnf repoquery it doesn't seem to be the case, and the other
pulseaudio-module-* packages I didn't install on my system seem to
share the same behavior.

Same explicit dependency with the xfce4-pulseaudio-plugin package.

I'm now much closer to giving pipewire a try.

Dridi
___
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

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

[Guido Aulisi]

Il giorno ven, 20/11/2020 alle 11.26 -0500, Ben Cotton ha scritto:
> https://fedoraproject.org/wiki/Changes/DefaultPipeWire
> 
> == Summary ==
> This change proposal is to route all audio from PulseAudio and JACK
> to
> the PipeWire Audio
> daemon by default.
> 
> == Owner ==
> * Name: [[User:Wtaymans| Wim Taymans]]
> * Email: wim.taym...@gmail.com
> 
> 
> == Detailed Description ==
> Currently, all desktop audio is handled by the PulseAudio daemon.
> Applications make use of the
> PulseAudio client library to communicate with the PulseAudio daemon
> that mixes and manages the audio streams from the clients.
> 
> The desktop shell (gnome-shell) and the control panel
> (gnome-control-panel) both use the
> Pulseaudio client libraries to manage the volume and configuration of
> the PulseAudio daemon.
> 
> This proposal is to replace the PulseAudio daemon with a functionally
> compatible implementation
> based on PipeWire. This means that all existing clients using the
> PulseAudio client library
> will continue to work as before, as well as applications shipped as
> Flatpak.
> 
> All PRO audio is handled with the JACK client library, which talks to
> the JACK server. This
> proposal will install a JACK client library replacement that talks
> directly to PipeWire. All
> existing PRO audio jack applications will then work on top of
> PipeWire.

For pro audio we should test very deeply with clients like ardour,
audacity, rosegarden, hydrogen and so on.
Pro audio is very sensible to latency and real time scheduling, and
jack is very mature in handling these requirements.
IMHO pipewire is too young to accomplish these tasks.
I think this should be an opt-in or out and that jack should remain as
an alternative to pipewire's jack module.

Ciao
Guido

... snip


___
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

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

[Artem Tim]

My experience is pretty OK with PipeWire in f33. Gaming also OK and seems like 
even fixed long standing issues in some games. Overall is better in terms of 
CPU utilization and quality (subjectively).

But one noticeable issue - no volume control in GNOME Shell, but it available 
in System Settings. There is also report about this in GNOME Flashback 
https://bugzilla.redhat.com/show_bug.cgi?id=1912062
___
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

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

[Michel Alexandre Salim]

On Mon, 2020-11-30 at 00:31 +0100, Dan Čermák wrote:
> "Wim Taymans"  writes:
> > * propose permanent switch for f35
> >   - it gets at least full cycle of testing (f34 + part of f33)
> > * re-evaluate situation for f35 beta freeze to make a default
> > switch.
> > 
> > Although a bit slower than expected, I guess more testing is good.
> > It sounds
> > like an acceptable plan to me.
> > I'm not sure how it works, if spinoffs can/want to make an earlier
> > switch?
> 
> Hm, I don't see a technical reason why a certain edition of Fedora
> couldn't ship with PipeWire by default earlier. Albeit I don't think
> that jumping ahead of the rest of the distro would reflect very well
> on
> the project, unless you call it "Fedora PipeWire Edition".
> 
It will be a spin in this case (Jam), not an edition, right? (And
editions sometimes do differ in what features they ship, e.g.
Workstation defaulted to btrfs in F33 but Server had not.

If the benefits for pro audio users outweigh any issues that cause the
default to be reverted to Pulseaudio, I can see it being valuable to
Jam to stick to Pipewire anyway while the balance goes the other way
around for non-pro users who don't use JACK.


Cheers,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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

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

[Tom Hughes via devel]

On 29/12/2020 01:41, Luya Tshimbalanga wrote:



I was trying it with Bose QC35 headphones.


It was 0.3.18 and as I say it was showing up as a device but
with no node that I could route audio to.


Maybe an extra step is required for that Bose QC35. Try to forget that device 
and reconnect.


That configuration you attached still seems to be missing the
extra "-e bluez5" on the pipewire-media-session line? or is the
comment there wrong when it says that is required?


I haven't needed to put "-e bluez5" as Galaxy Buds+ worked without extra 
configuration on a first try.


I had another play with it and I can confirm that I now have
bluetooth working - it does work out of the box but has a habit
of switching back to the on board sound for new audio streams
unless you add that "-e bluez5" argument.

What doesn't work at all, and this is likely what was causing
my problems before, is fast user switching.

That doesn't work with traditional pulseaudio for bluetooth
but you can work around that by disabling the bluetooth modules
in .config/pulse/default.pa for all bar one user if you are
happy only using bluetooth for a single user.

With pipewire not only does it not work for bluetooth, it
doesn't work for the on board sound either - you have to
stop the pipewire service for one user before switching to
the other one or it can't use the sound card as the other
instance still has it open.

I did try and use the (not shipped in Fedora) system service
units for pipewire but I couldn't get them to work.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

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

[Luya Tshimbalanga]

> I was trying it with Bose QC35 headphones.
> 
> 
> It was 0.3.18 and as I say it was showing up as a device but
> with no node that I could route audio to.
> 
Maybe an extra step is required for that Bose QC35. Try to forget that device 
and reconnect.

> That configuration you attached still seems to be missing the
> extra "-e bluez5" on the pipewire-media-session line? or is the
> comment there wrong when it says that is required?
> 
I haven't needed to put "-e bluez5" as Galaxy Buds+ worked without extra 
configuration on a first try.

Luya
___
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

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

[Tom Hughes via devel]

On 27/12/2020 20:07, Luya Tshimbalanga wrote:


On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote:

On 20/11/2020 16:26, Ben Cotton wrote:

<

  - bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.


I was unable to get this to work.


Works with Galaxy Buds+ as highlighted below:


I was trying it with Bose QC35 headphones.


The first problem is that bluetooth is not actually enabled
by default so you have to edit /etc/pipewire/pipewire.conf and
tell it to add "-e bluez5" when starting the session manager.


Which version of pipewire was used on your system? Pipewire 0.3.18 
enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to 
resuming for the reopened lid of a laptop. Workaround is with the 
command for terminal "systemctl --user restart pipewire.service 
pipewire-pulse.service". See attached pipewire.conf with include bleuz5 
enabled by default.


It was 0.3.18 and as I say it was showing up as a device but
with no node that I could route audio to.

That configuration you attached still seems to be missing the
extra "-e bluez5" on the pipewire-media-session line? or is the
comment there wrong when it says that is required?


The final straw though was that fast user switching seems to
completely break it. I assume that the daemon doesn't release
the audio device when you switch to a different desktop to
something because once I started a second session things got
horribly confused and I wound up with one desktop where audio
worked and one where it didn't work at all.


No issue on my desktop running Rawhide. Maybe some issues are user error 
like using old version of pipewire. Update your system and make sure 
pipewire version is 0.3.18 whose pipewire-pulseaudio properly handle 
dependencies. Should you see Steam from RPM Fusion being removed, grab 
the latest version from their Koji page which fixes the problem.


I don't use steam so it's nothing to do with that.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

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

[Luya Tshimbalanga]

On 2020-12-15 10:52 a.m., Tom Seewald wrote:

Gary Buhrmaster wrote on Mon, Dec 14, 2020:

With updates-testing enabled here, it's much better than last month (no
more gdm being removed), but there still are a few pulseaudio direct
dependencies:

Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until 
that conflict is resolved it is going to prevent a lot of people from being 
able to test pipewire since it will mean removing their ability to use steam 
and all of the games tied to it.



Resolved on steam 1.0.0.68-6

https://koji.rpmfusion.org/koji/packageinfo?packageID=413

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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

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

[Luya Tshimbalanga]

On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote:

On 20/11/2020 16:26, Ben Cotton wrote:


== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.


So I tried this in F33 with the packages from updates-testing
and I'm afraid to say it didn't end well...


Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:

  - patcl info should now list: Server Name: PulseAudio (on PipeWire 
0.3.x)


As pactl was removed by the switch I couldn't test this.


pactl command is still present after replacing pulseaudio by 
pipewire-pulseaudio.



pactl info
Server String: /run/user/1000/pulse/native
Library Protocol Version: 34
Server Protocol Version: 34
Is Local: yes
Client Index: 78
Tile Size: 65472
Server Name: PulseAudio (on PipeWire 0.3.18)
Server Version: 14.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-:03:00.6.analog-stereo
Default Source: alsa_input.pci-:03:00.6.analog-stereo
Cookie: 5667:4fbd




  - gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
  switch.


This worked initially, but see later.


  - pavucontrol: check volumes in the input devices tabs and check the
microphone volumes


Didn't test this.


Worked fine.





  - firefox: check out a website with audio/video such as youtube and
verify that audio works as
 usual. Check out a website with a video chat test page
(bluejeans.com/111).


Didn't test this.

Works.



  - rhythmbox: check if playback works as expected


This worked initially, but see later.


Works here.





  - bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.


I was unable to get this to work.


Works with Galaxy Buds+ as highlighted below:

pactl info
Server String: /run/user/1000/pulse/native
Library Protocol Version: 34
Server Protocol Version: 34
Is Local: yes
Client Index: 97
Tile Size: 65472
Server Name: PulseAudio (on PipeWire 0.3.18)
Server Version: 14.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: api.bluez5.a2dp.sink.Galaxy Buds+ (11C1)
Default Source: alsa_input.pci-:03:00.6.analog-stereo
Cookie: 4766:6514



The first problem is that bluetooth is not actually enabled
by default so you have to edit /etc/pipewire/pipewire.conf and
tell it to add "-e bluez5" when starting the session manager.


Which version of pipewire was used on your system? Pipewire 0.3.18 
enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to 
resuming for the reopened lid of a laptop. Workaround is with the 
command for terminal "systemctl --user restart pipewire.service 
pipewire-pulse.service". See attached pipewire.conf with include bleuz5 
enabled by default.





After that my headphones who show up as a device in pw-cli
but not as a target I could send sound to.


An example with Galaxy Buds+:

    id 84, type PipeWire:Interface:Node/3
     factory.id = "7"
     client.id = "31"
     device.id = "83"
     node.description = "Galaxy Buds+ (11C1)"
     node.name = "api.bluez5.a2dp.sink.Galaxy Buds+ (11C1)"
     media.class = "Audio/Sink"
    id 85, type PipeWire:Interface:Port/3
     object.path = "Galaxy Buds+ (11C1):playback_0"
     format.dsp = "32 bit float mono audio"
     node.id = "84"
     audio.channel = "FL"
     port.name = "playback_FL"
     port.direction = "in"
     port.physical = "true"
     port.terminal = "true"
     port.alias = "Galaxy Buds+ (11C1):playback_FL"
    id 86, type PipeWire:Interface:Port/3
     object.path = "Galaxy Buds+ (11C1):monitor_0"
     format.dsp = "32 bit float mono audio"
     node.id = "84"
     audio.channel = "FL"
     port.name = "monitor_FL"
     port.direction = "out"
     port.alias = "Galaxy Buds+ (11C1):monitor_FL"
    id 87, type PipeWire:Interface:Port/3
     object.path = "Galaxy Buds+ (11C1):playback_1"
     format.dsp = "32 bit float mono audio"
     node.id = "84"
     audio.channel = "FR"
     port.name = "playback_FR"
     port.direction = "in"
     port.physical = "true"
     port.terminal = "true"
     port.alias = "Galaxy Buds+ (11C1):playback_FR"
    id 88, type PipeWire:Interface:Port/3
     object.path = "Galaxy Buds+ (11C1):monitor_1"
     format.dsp = "32 bit float mono audio"
     node.id = "84"
     audio.channel = "FR"
     port.name = "monitor_FR"
     port.direction = "out"
     port.alias = "Galaxy Buds+ (11C1):monitor_FR"



The final straw though was that fast user switching seems to
completely break it. I assume that the daemon doesn't release
the audio device when you 

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

[Tom Hughes via devel]

On 20/11/2020 16:26, Ben Cotton wrote:


== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.


So I tried this in F33 with the packages from updates-testing
and I'm afraid to say it didn't end well...


Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:

  - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)


As pactl was removed by the switch I couldn't test this.


  - gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
  switch.


This worked initially, but see later.


  - pavucontrol: check volumes in the input devices tabs and check the
microphone volumes


Didn't test this.


  - firefox: check out a website with audio/video such as youtube and
verify that audio works as
 usual. Check out a website with a video chat test page
(bluejeans.com/111).


Didn't test this.


  - rhythmbox: check if playback works as expected


This worked initially, but see later.


  - bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.


I was unable to get this to work.

The first problem is that bluetooth is not actually enabled
by default so you have to edit /etc/pipewire/pipewire.conf and
tell it to add "-e bluez5" when starting the session manager.

After that my headphones who show up as a device in pw-cli
but not as a target I could send sound to.

The final straw though was that fast user switching seems to
completely break it. I assume that the daemon doesn't release
the audio device when you switch to a different desktop to
something because once I started a second session things got
horribly confused and I wound up with one desktop where audio
worked and one where it didn't work at all.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

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

[Mauro Carvalho Chehab]

Em Mon, 14 Dec 2020 23:04:23 +
Gary Buhrmaster  escreveu:
> On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab
>  wrote:
>   
> > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing
> 
> I needed to add --enablerepo=updates-testing
> 
> Also, you may need to (as yourself) perform a
> 
> $ systemctl --user enable pipewire pipewire-pulse  

There are still broken dependecies when using with Jack protocol:

# dnf install pipewire-jack-audio-connection-kit --allowerasing 
--enablerepo=updates-testing
Last metadata expiration check: 0:14:07 ago on Sat Dec 19 19:33:38 2020.
Dependencies resolved.
==
 PackageArchitecture
   Version  Repository  
 Size
==
Installing:
 pipewire-jack-audio-connection-kit x86_64  
   0.3.18-1.fc33updates-testing 
 12 k
Removing dependent packages:
 SDL_mixer  x86_64  
   1.2.12-21.fc33   @fedora 
201 k
 a2jmidid   x86_64  
   9-4.fc33 @fedora 
130 k
 amsynthx86_64  
   1.12.1-1.fc33@updates
328 k
 anki   noarch  
   2.1.15-3.fc33@fedora 
 12 M
 ardour6x86_64  
   6.3.0-1.fc33 @fedora 
 63 M
 ardour6-backend-alsa   x86_64  
   6.3.0-1.fc33 @fedora 
281 k
 ardour6-backend-dummy  x86_64  
   6.3.0-1.fc33 @fedora 
147 k
 ardour6-backend-jack   x86_64  
   6.3.0-1.fc33 @fedora 
184 k
 ardour6-backend-pulseaudio x86_64  
   6.3.0-1.fc33 @fedora 
110 k
 arpage x86_64  
   0.3.3-30.fc33@fedora 
455 k
 aubio  x86_64  
   0.4.9-7.fc33 @fedora 
452 k
 audacity   x86_64  
   2.3.3-7.fc33 @fedora 
 26 M
 avidemux   x86_64  
   2.7.6-3.fc33 @rpmfusion-free 
177  
 avidemux-libs  x86_64  
   2.7.6-3.fc33 @rpmfusion-free 
 14 M
 avidemux-qtx86_64  
   2.7.6-3.fc33 @rpmfusion-free 
4.3 M
 calf   x86_64  
   0.90.3-7.fc33@fedora 
 19 M
 denemo x86_64  
   2.4.0-2.fc33 @fedora 
 29 M
 dssi   x86_64  
   1.1.1-20.fc33@fedora 
134 k
 ffmpeg x86_64  
   4.3.1-11.fc33 

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

[Gergely Gombos via devel]

Hi,

I'm the packager of pulseaudio-module-bluetooth-freeworld in rpmfusion. That 
library provides AAC, LDAC and aptX for Bluetooth users.

What seems to be the case is that pipewire can already be built with
aptX and ldac support: 
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/meson.build#L31-32

There's a lot of work going on to improve Bluetooth support, which is great!

We already have libldac in Fedora, and here's a review request for libopenaptx: 
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
(I appreciate if some of you could take a look)

This way, we could update the pipewire package to build with these in Fedora 
and have first-class support for these codecs.

Best regards,
Greg
___
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

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

[Leigh Scott]

> After removing pulseaudio package I have no sound and pipewire-pulse doesn't
> autostart, pulseaudio used /etc/xdg/autostart to start.
> Even after activating pipewire-pulse using systemctl it still has no sound.
> 
CONFESSION:  I have found the issue :blush: 

I was remotely (virt-manager over ssh) accessing the VM hosted on my 
workstation, it works fine running host.
___
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

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

[Neal Gompa]

On Wed, Dec 16, 2020 at 5:18 AM Leigh Scott  wrote:
>
> > Maybe you would like to elaborate, because I have switched yesterday and
> > so far I can't see any difference in functionality.
> >
> >
> > Vít
> >
> >
> > Dne 16. 12. 20 v 9:21 Leigh Scott napsal(a):
>
> After removing pulseaudio package I have no sound and pipewire-pulse doesn't 
> autostart, pulseaudio used /etc/xdg/autostart to start.
> Even after activating pipewire-pulse using systemctl it still has no sound.
>
> $ rpm -qa --requires cinnamon\* |grep pulse
> libpulse.so.0()(64bit)
> libpulse.so.0(PULSE_0)(64bit)
> libpulse-mainloop-glib.so.0()(64bit)
> libpulse-mainloop-glib.so.0(PULSE_0)(64bit)
> libpulse.so.0()(64bit)
> libpulse.so.0(PULSE_0)(64bit)
>

I'm literally working on getting the automatic activation working. I'm
sorry that it's not ready right now, but I'm still going through and
fixing it. I'm testing around Fedora KDE at the moment, and while it's
"working" it's not fully right just yet.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Leigh Scott]

> Maybe you would like to elaborate, because I have switched yesterday and 
> so far I can't see any difference in functionality.
> 
> 
> Vít
> 
> 
> Dne 16. 12. 20 v 9:21 Leigh Scott napsal(a):

After removing pulseaudio package I have no sound and pipewire-pulse doesn't 
autostart, pulseaudio used /etc/xdg/autostart to start.
Even after activating pipewire-pulse using systemctl it still has no sound.

$ rpm -qa --requires cinnamon\* |grep pulse
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)(64bit)
libpulse-mainloop-glib.so.0()(64bit)
libpulse-mainloop-glib.so.0(PULSE_0)(64bit)
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)(64bit)

___
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

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

[Vít Ondruch]

Maybe you would like to elaborate, because I have switched yesterday and 
so far I can't see any difference in functionality.



Vít


Dne 16. 12. 20 v 9:21 Leigh Scott napsal(a):

Why push this half baked feature for F34, I just tried the F34 cinnamon spin 
and this feature isn't even alpha quality.
I wont be switching cinnamon or any rpmfusion packages I maintain to it till 
it's rock steady release quality.
___
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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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

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

[Leigh Scott]

Why push this half baked feature for F34, I just tried the F34 cinnamon spin 
and this feature isn't even alpha quality.
I wont be switching cinnamon or any rpmfusion packages I maintain to it till 
it's rock steady release quality.
___
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

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

[Dominique Martinet]

Wim Taymans wrote on Tue, Dec 15, 2020:
> > In particular I'm worried alsa programs will stop working.
> 
> There is a pipewire-alsa package to support alsa programs

Aha! I had missed it, thanks.

> > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's
> > pulseaudio implementation?
> 
> It is but then you go through an extra layer of emulation, it's better to
> remove the pulseaudio one and use the pipewire one if you remove the
> pulseaudio daemon.

Definitely, I agree pipewire-alsa suffices and is better (although I'm
not sure alsa-plugins-pulseaudio should have unfullfilled dependncies
from pipewire-pulseaudio, it's probably saner to have it autoremoved by
default to avoid multiple interfaces to the same service)

> > or some new alsa-plugins-pipewire should be pulled in at least to
> > keep things working one way or another) 
> 
> Yes, it should somehow be pulled in, how should that be done? A Suggests:
> for pipewire-pulse maybe?

I'm not too familiar on this, but a recommends (rather than suggests
which will likely be ignored by dnf afaiu) on pipewire-pulseaudio sounds
good despite being not directly related to pulseaudio.

I'm honestly not sure what would be best, but pulling it without the
pipewire service enable sounds more harmful than good...
pipewire-pulseaudio sounds like a good reinsurance that pipewire will
likely be running.



Note: I've now switched packages and also had to enable/start the
service:
 systemctl --user enable --now pipewire-pulse.socket

I would suggest installing a preset file that would tell systemd to
enable it by default if possible?

It looks like pipewire.socket has one from
/usr/lib/systemd/user-preset/90-default-user.preset (in
fedora-release-common-33-2.noarch) which wasn't obvious to find, I
didn't check if fedora34 also enables pipewire-pulse but if not it
definitely should (or pipewire should ship its own presets)


Thanks,
-- 
Dominique
___
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

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

[Tom Seewald]

> Gary Buhrmaster wrote on Mon, Dec 14, 2020:
> 
> With updates-testing enabled here, it's much better than last month (no
> more gdm being removed), but there still are a few pulseaudio direct
> dependencies:

Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until 
that conflict is resolved it is going to prevent a lot of people from being 
able to test pipewire since it will mean removing their ability to use steam 
and all of the games tied to it.
___
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

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

[Wim Taymans]

Hi,

> In particular I'm worried alsa programs will stop working.

There is a pipewire-alsa package to support alsa programs

> Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's
> pulseaudio implementation?

It is but then you go through an extra layer of emulation, it's better to
remove
the pulseaudio one and use the pipewire one if you remove the pulseaudio
daemon.

> (I see there's also an alsa-plugins-jack, I guess that might work but I
> don't have it installed right now;

This should also work but again using an extra layer of emulation.

> or some new alsa-plugins-pipewire
> should be pulled in at least to keep things working one way or another)

Yes, it should somehow be pulled in, how should that be done? A Suggests:
for pipewire-pulse maybe?

Wim

On Tue, Dec 15, 2020 at 8:09 AM Dominique Martinet 
wrote:

> Gary Buhrmaster wrote on Mon, Dec 14, 2020:
> > On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab
> >  wrote:
> >
> > > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing
> >
> > I needed to add --enablerepo=updates-testing
>
> With updates-testing enabled here, it's much better than last month (no
> more gdm being removed), but there still are a few pulseaudio direct
> dependencies:
> # dnf swap pulseaudio pipewire-pulseaudio --allowerasing
> Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26
> CET.
> Dependencies resolved.
>
> ==
>  Package  ArchVersion Repository
>  Size
>
> ==
> Installing:
>  pipewire-pulseaudio  x86_64  0.3.17-3.fc33   updates-testing
> 14 k
> Upgrading:
>  pipewire x86_64  0.3.17-3.fc33   updates-testing
>  118 k
>  pipewire-gstreamer   x86_64  0.3.17-3.fc33   updates-testing
> 52 k
>  pipewire-libsx86_64  0.3.17-3.fc33   updates-testing
>  922 k
> Removing:
>  pulseaudio   x86_64  14.0-2.fc33 @updates-testing
> 4.0 M
> Removing dependent packages:
>  alsa-plugins-pulseaudio  x86_64  1.2.2-3.fc33@fedora
>  121 k
>  pulseaudio-module-bluetooth  x86_64  14.0-2.fc33 @updates-testing
> 231 k
>  pulseaudio-module-x11x86_64  14.0-2.fc33 @updates-testing
>  78 k
>  xfce4-pulseaudio-plugin  x86_64  0.4.3-3.fc33@fedora
>  447 k
>
>
> In particular I'm worried alsa programs will stop working.
> Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's
> pulseaudio implementation?
> (I see there's also an alsa-plugins-jack, I guess that might work but I
> don't have it installed right now; or some new alsa-plugins-pipewire
> should be pulled in at least to keep things working one way or another)
>
> --
> Dominique
> ___
> 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
>
___
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

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

[Dominique Martinet]

Gary Buhrmaster wrote on Mon, Dec 14, 2020:
> On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab
>  wrote:
> 
> > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing
> 
> I needed to add --enablerepo=updates-testing

With updates-testing enabled here, it's much better than last month (no
more gdm being removed), but there still are a few pulseaudio direct
dependencies:
# dnf swap pulseaudio pipewire-pulseaudio --allowerasing
Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26 CET.
Dependencies resolved.
==
 Package  ArchVersion Repository Size
==
Installing:
 pipewire-pulseaudio  x86_64  0.3.17-3.fc33   updates-testing14 k
Upgrading:
 pipewire x86_64  0.3.17-3.fc33   updates-testing   118 k
 pipewire-gstreamer   x86_64  0.3.17-3.fc33   updates-testing52 k
 pipewire-libsx86_64  0.3.17-3.fc33   updates-testing   922 k
Removing:
 pulseaudio   x86_64  14.0-2.fc33 @updates-testing  4.0 M
Removing dependent packages:
 alsa-plugins-pulseaudio  x86_64  1.2.2-3.fc33@fedora   121 k
 pulseaudio-module-bluetooth  x86_64  14.0-2.fc33 @updates-testing  231 k
 pulseaudio-module-x11x86_64  14.0-2.fc33 @updates-testing   78 k
 xfce4-pulseaudio-plugin  x86_64  0.4.3-3.fc33@fedora   447 k


In particular I'm worried alsa programs will stop working.
Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's
pulseaudio implementation?
(I see there's also an alsa-plugins-jack, I guess that might work but I
don't have it installed right now; or some new alsa-plugins-pipewire
should be pulled in at least to keep things working one way or another)

-- 
Dominique
___
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

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

[Gary Buhrmaster]

On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab
 wrote:

> # dnf swap pulseaudio pipewire-pulseaudio --allowerasing

I needed to add --enablerepo=updates-testing

Also, you may need to (as yourself) perform a

$ systemctl --user enable pipewire pipewire-pulse


In limited testing it seems to work for my use cases.
___
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

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

[Mauro Carvalho Chehab]

Em Sun, 22 Nov 2020 12:17:06 +0100
Vitaly Zaitsev via devel  escreveu:

> On 22.11.2020 10:05, Mattia Verga via devel wrote:
> > I think the package name is wrong, it should be pipewire-pulseaudio.
> > However, it seems it doesn't correctly replace pulseaudio:
> > 
> > # dnf install pipewire-pulseaudio --enablerepo=updates-testing  
> 
> This is absolutely fine. You should use dnf swap instead:
> 
> dnf swap pulseaudio pipewire-pulseaudio --allowerasing
> 

Tried it today (tested using a COPR repo with pipewire-0.3.17, as
with 0.3.15, it would try to remove a large number of packages which
depends on PA).

There are still some packages being removed, probably due to wrong
dependency chains:

# dnf swap pulseaudio pipewire-pulseaudio --allowerasing

Last metadata expiration check: 2:23:59 ago on Mon Dec 14 09:09:34 2020.
Package pipewire-pulseaudio-0.3.17-3.fc33.x86_64 is already installed.
Dependencies resolved.
===
 Package  Architecture Version  
RepositorySize
===
Removing:
 pulseaudio   x86_64   14.0-2.fc33  
@updates 4.0 M
Removing dependent packages:
 alsa-plugins-pulseaudio  i686 1.2.2-3.fc33 
@fedora  123 k
 alsa-plugins-pulseaudio  x86_64   1.2.2-3.fc33 
@fedora  121 k
 pulseaudio-module-bluetooth  x86_64   14.0-2.fc33  
@updates 231 k
 pulseaudio-module-gconf  x86_64   14.0-2.fc33  
@updates  40 k
 pulseaudio-module-gsettings  x86_64   14.0-2.fc33  
@updates  51 k
 pulseaudio-module-x11x86_64   14.0-2.fc33  
@updates  78 k
 pulseaudio-module-zeroconf   x86_64   14.0-2.fc33  
@updates 194 k
 pulseaudio-qpaeq x86_64   14.0-2.fc33  
@updates 106 k
 steami686 1.0.0.68-2.fc33  
@rpmfusion-nonfree-updates   2.9 M
Removing unused dependencies:
 gamemode i686 1.6-1.fc33   
@updates 248 k
 gamemode x86_64   1.6-1.fc33   
@updates 276 k
 gnome-shell-extension-gamemode   noarch   1-4.fc33 
@fedora   46 k
 inih i686 49-2.fc33
@fedora   25 k
 inih x86_64   49-2.fc33
@fedora   25 k
 libatomici686 10.2.1-9.fc33
@updates  32 k
 libdbusmenu-gtk3 i686 16.04.0-16.fc33  
@fedora   96 k
 libnsl   i686 2.32-2.fc33  
@updates 160 k
 libpng12 i686 1.2.57-12.fc33   
@fedora  450 k
 mpg123-plugins-pulseaudiox86_64   1.26.2-2.fc33
@fedora   16 k

Transaction Summary
===
Remove  20 Packages

Also, PipeWire is not working fine with Mate Desktop volume control
via media keys (XF86AudioLowerVolume, XF86AudioRiseVolume, 
XF86AudioMuteVolume). I opened a BZ for such issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1907617

-

I ran a few quick tests using both PA and Jack apps.

I didn't notice any major issue on my tests so far. 

Regards,
Mauro
___
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

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

[Lyes Saadi]

Wouldn't using a "Conflicts=" option in the systemd user unit file work 
while preventing both from running simultaneously? (I mean, except when 
it is started from cli directly.)


Le 05/12/2020 à 21:43, Erich Eickmeyer a écrit :

On 12/5/20 12:39 PM, Naheem Zaffar wrote:


I understand the need for replacing pulseaudio package when 
upgrading, but it should be possible to have both installed and have 
the service from only one activated? Atleast for current fedora that 
will make it easier to test and switch between implementations.


The point is you don't want/shouldn't have both pipewire and 
pulseaudio installed simultaneously since pipewire-pulseaudio is a 
drop-in replacement.


So no, that would be a bad idea.

--
Erich Eickmeyer
Maintainer
Fedora Jam

___
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

___
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

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

[Erich Eickmeyer]

On 12/5/20 12:39 PM, Naheem Zaffar wrote:


I understand the need for replacing pulseaudio package when upgrading, 
but it should be possible to have both installed and have the service 
from only one activated? Atleast for current fedora that will make it 
easier to test and switch between implementations.


The point is you don't want/shouldn't have both pipewire and pulseaudio 
installed simultaneously since pipewire-pulseaudio is a drop-in replacement.


So no, that would be a bad idea.

--
Erich Eickmeyer
Maintainer
Fedora Jam

___
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

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

[Naheem Zaffar]

On Fri, 20 Nov 2020 at 16:27, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/DefaultPipeWire
>
>
>
> == Scope ==
> * Proposal owners:
> We would make a pipewire-pulse package that provides the same features
> as the pulseaudio (daemon) package.
> We would only provide a drop-in replacement daemon, the pulseaudio
> client libraries will remain unchanged.
>
> The idea is that when installing pipewire-pulse, only the pulseaudio
> package is removed and replaced by the
> pipewire-pulse implementation.
>

Is it required to make the packages conflict?

The implementation that is used needs to have its service activated.

I understand the need for replacing pulseaudio package when upgrading, but
it should be possible to have both installed and have the service from only
one activated? Atleast for current fedora that will make it easier to test
and switch between implementations.
___
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

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

[Alexander Bokovoy]

On to, 26 marras 2020, Alexander Bokovoy wrote:

On to, 26 marras 2020, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:

On ke, 25 marras 2020, Tomáš Popela wrote:

On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
wrote:


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.



Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
Chrome/Chromium?


Yes! And nothing works. It worked for me partially in F33 beta, not
anymore since F33 release. May be before that -- I did not track back
exact date when things changed to not work.


It also doesn't work for me: with the chrome option enabled, the list
of windows to share and the list of screens to share are both empty.
In addition to the chrome dialog I get two popups asking me which
window to share, but selecting something there doesn't seem to have any
effect.


I get the same behavior in Chrome but in Firefox it shows proper dialogs
and still fails to send anything out.


With the help of Tomas and Jan, we've got this sorted out. Upgrade to
pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to
share the screen. It doesn't help with UX of pipewire portal dialogs but
this is something I can live with for time being.


--
/ 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

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

[J. Bruce Fields]

On Tue, Nov 24, 2020 at 08:06:41PM +0100, Joël Krähemann wrote:
> On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa  wrote:
> > 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.

FWIW, as an amateur musician, bandmates send me youtube links for songs
they want to cover, and as part of learning the song I may play along
with the youtube video, record it to an Ardour track, etc.

All currently doable on Fedora but there are some hoops to jump through.

(Very much looking forward to PipeWire.)

--b.
___
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

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

[Dan Čermák]

Adam Williamson  writes:

> On Mon, 2020-11-30 at 00:24 +0100, Dan Čermák wrote:
>> Neal Gompa  writes:
>> 
>> Now, this does not mean that we shouldn't test audio in Fedora's openQA
>> (we don't atm), as that is still a valuable regression test. But we
>> won't be able to cover a lot of the more interesting use cases where I
>> would expect [2] that most of current the bugs are. Those will only get
>> found by running this on real world hardware by folks that have their
>> working setups.
>
> Yeah, I looked into it before and this is basically why I didn't bother
> implementing it; it doesn't buy us much more than we're getting
> naturally from human testing anyway.

Well, except that a human needn't lift a finger anymore to check if
there's actually sound coming out of vlc/mpv/firefox/etc. ;-).

Now checking whether that's actually the sound that you expect or
whether it has the correct volume is an entirely different story of
course and I'm afraid that's something where we'll have to rely on
humans or $shinyMlAiSolutionThatSolvesAllOurProblems.


Cheers,

Dan


signature.asc
Description: PGP signature
___
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

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

[Adam Williamson]

On Mon, 2020-11-30 at 00:24 +0100, Dan Čermák wrote:
> Neal Gompa  writes:
> 
> > 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?
> 
> While it is technically possible to do audio testing in openQA, it is
> not really used a lot. The main reason is that the current
> implementation is rather brittle (albeit pretty clever): it converts the
> audio signal to an image (afaik it plots the intensity) and does its
> usual needle comparison. Unfortunately this does not work that well in
> practice and the one of the few audio tests that openSUSE has in openQA
> is a constant source of trouble, while catching very few bugs [1].
> 
> But even if openQA had a very reliable way to test audio, I'm afraid it
> wouldn't really help us out too much here. openQA is realistically only
> going to be able to cover your basic use cases, but it's not going to be
> able to test all the special audio setups that all the people who are
> into audio have at home (as that would require their hardware &
> software). So openQA would only test what the PipeWire devs are probably
> testing already anyway and it would not provide a whole lot of
> additional interesting test cases.
> 
> Now, this does not mean that we shouldn't test audio in Fedora's openQA
> (we don't atm), as that is still a valuable regression test. But we
> won't be able to cover a lot of the more interesting use cases where I
> would expect [2] that most of current the bugs are. Those will only get
> found by running this on real world hardware by folks that have their
> working setups.

Yeah, I looked into it before and this is basically why I didn't bother
implementing it; it doesn't buy us much more than we're getting
naturally from human testing anyway.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
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

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

[Dan Čermák]

"Wim Taymans"  writes:

> So, the current sentiment is:
>
> * provide an easy way to test in f33, either copr or with regular packages.
>- rawhide is a not a good place to get good testing anyway
> * encourage people to test. Provide instructions on how to do this and how to
>leave feedback.
> * Carry this over to f34, probably with just the packages/easier switch.

Yeah, I have the feeling that we should give this a good round of
testing for a whole release cycle at least before we PipeWire the
default. Especially if we make it simple to switch between PulseAudio &
PipeWire, we'll give the developers much more usage data than from a few
test days.

> * propose permanent switch for f35
>   - it gets at least full cycle of testing (f34 + part of f33)
> * re-evaluate situation for f35 beta freeze to make a default switch.
>
> Although a bit slower than expected, I guess more testing is good. It sounds
> like an acceptable plan to me.
> I'm not sure how it works, if spinoffs can/want to make an earlier
> switch?

Hm, I don't see a technical reason why a certain edition of Fedora
couldn't ship with PipeWire by default earlier. Albeit I don't think
that jumping ahead of the rest of the distro would reflect very well on
the project, unless you call it "Fedora PipeWire Edition".


Cheers,

Dan


signature.asc
Description: PGP signature
___
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

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

[Dan Čermák]

Neal Gompa  writes:

> 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?

While it is technically possible to do audio testing in openQA, it is
not really used a lot. The main reason is that the current
implementation is rather brittle (albeit pretty clever): it converts the
audio signal to an image (afaik it plots the intensity) and does its
usual needle comparison. Unfortunately this does not work that well in
practice and the one of the few audio tests that openSUSE has in openQA
is a constant source of trouble, while catching very few bugs [1].

But even if openQA had a very reliable way to test audio, I'm afraid it
wouldn't really help us out too much here. openQA is realistically only
going to be able to cover your basic use cases, but it's not going to be
able to test all the special audio setups that all the people who are
into audio have at home (as that would require their hardware &
software). So openQA would only test what the PipeWire devs are probably
testing already anyway and it would not provide a whole lot of
additional interesting test cases.

Now, this does not mean that we shouldn't test audio in Fedora's openQA
(we don't atm), as that is still a valuable regression test. But we
won't be able to cover a lot of the more interesting use cases where I
would expect [2] that most of current the bugs are. Those will only get
found by running this on real world hardware by folks that have their
working setups.


Cheers,

Dan

Footnotes:
[1]  I've heard this only, take this with a pinch of salt.

[2]  emphasis on _expect_, not _know_. I really have no insight in the
 maturity of PiperWire.


signature.asc
Description: PGP signature
___
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

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

[Alexander Bokovoy]

On to, 26 marras 2020, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:

On ke, 25 marras 2020, Tomáš Popela wrote:
>On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
>wrote:
>
>>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.
>>
>
>Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
>have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
>Chrome/Chromium?

Yes! And nothing works. It worked for me partially in F33 beta, not
anymore since F33 release. May be before that -- I did not track back
exact date when things changed to not work.


It also doesn't work for me: with the chrome option enabled, the list
of windows to share and the list of screens to share are both empty.
In addition to the chrome dialog I get two popups asking me which
window to share, but selecting something there doesn't seem to have any
effect.


I get the same behavior in Chrome but in Firefox it shows proper dialogs
and still fails to send anything out.

--
/ 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

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

[Vít Ondruch]

Dne 26. 11. 20 v 14:38 Neal Gompa napsal(a):

On Thu, Nov 26, 2020 at 8:35 AM Zbigniew Jędrzejewski-Szmek
 wrote:

On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:

On ke, 25 marras 2020, Tomáš Popela wrote:

On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
wrote:


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.


Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
Chrome/Chromium?

Yes! And nothing works. It worked for me partially in F33 beta, not
anymore since F33 release. May be before that -- I did not track back
exact date when things changed to not work.

It also doesn't work for me: with the chrome option enabled, the list
of windows to share and the list of screens to share are both empty.
In addition to the chrome dialog I get two popups asking me which
window to share, but selecting something there doesn't seem to have any
effect.


Something about Firefox makes it request for me three times, but after
that it seems to work.





But once you loose the selection dialog, you won't get it again anymore 
:/ But this seems to be FF issue, not Pipewire.



Vít



OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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

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

[Neal Gompa]

On Thu, Nov 26, 2020 at 8:35 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
> > On ke, 25 marras 2020, Tomáš Popela wrote:
> > >On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
> > >wrote:
> > >
> > >>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.
> > >>
> > >
> > >Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
> > >have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
> > >Chrome/Chromium?
> >
> > Yes! And nothing works. It worked for me partially in F33 beta, not
> > anymore since F33 release. May be before that -- I did not track back
> > exact date when things changed to not work.
>
> It also doesn't work for me: with the chrome option enabled, the list
> of windows to share and the list of screens to share are both empty.
> In addition to the chrome dialog I get two popups asking me which
> window to share, but selecting something there doesn't seem to have any
> effect.
>

Something about Firefox makes it request for me three times, but after
that it seems to work.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
> On ke, 25 marras 2020, Tomáš Popela wrote:
> >On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
> >wrote:
> >
> >>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.
> >>
> >
> >Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
> >have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
> >Chrome/Chromium?
> 
> Yes! And nothing works. It worked for me partially in F33 beta, not
> anymore since F33 release. May be before that -- I did not track back
> exact date when things changed to not work.

It also doesn't work for me: with the chrome option enabled, the list
of windows to share and the list of screens to share are both empty.
In addition to the chrome dialog I get two popups asking me which
window to share, but selecting something there doesn't seem to have any
effect.

Zbyszek
___
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

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

[Vít Ondruch]

Running Rawhide, I don't think there is a need to postpone this, if the 
PipeWire and PA are easily swap-able and that should be possible next 
week as far as I understand your plan. That means everybody will be able 
to switch back to PA if there are issues. That should be good for 
Rawhide as well as F34.



Vít


Dne 25. 11. 20 v 15:18 Wim Taymans napsal(a):

So, the current sentiment is:

* provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
* encourage people to test. Provide instructions on how to do this and how to
leave feedback.
* Carry this over to f34, probably with just the packages/easier switch.
* propose permanent switch for f35
   - it gets at least full cycle of testing (f34 + part of f33)
* re-evaluate situation for f35 beta freeze to make a default switch.

Although a bit slower than expected, I guess more testing is good. It sounds
like an acceptable plan to me.
I'm not sure how it works, if spinoffs can/want to make an earlier switch?

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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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

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

[Luya Tshimbalanga]

On 2020-11-25 6:18 a.m., Wim Taymans wrote:

So, the current sentiment is:

* provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway


That will be great as a lab suite maintainer. pipewire-pulse is 
currently missing as package and the documentation needs update. Rather 
sooner should pipewire aimed to default on Fedora 34 which will follow 
the 4 F principles.


I also run Rawhide on desktop.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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

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

[Dylan M Taylor]

> * re-evaluate situation for f35 beta freeze to make a default switch.
> 
> Although a bit slower than expected, I guess more testing is good. It sounds
> like an acceptable plan to me.
> I'm not sure how it works, if spinoffs can/want to make an earlier switch?

I feel that based on testing if there are no caveats discovered the switch 
could still be made for F34 as the default and there could be an easy switch 
back to PulseAudio if users need it for some reason.
___
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

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

[Dylan M Taylor]

I can confirm that this works great. I've used it with BlueJeans without issue.
___
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

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

[Kalev Lember]

On Wed, Nov 25, 2020 at 7:01 PM Kevin Fenzi  wrote:

> I don't think we need to go this slow, unless we run into problems...
>
> If we run into problems in f34, we can just revert and try again for
> f35. Of course that does assume that it's made easy to switch the
> default back.
>
> So, for me personally, I think having a way to test in f33 would be
> great and provide more feedback, but I think we should move ahead for
> f34 unless there's blockers, in which case we revert back and try for
> f35.
>

What Kevin said reflects my thoughts as well. It's worth trying to aim for
f34 and fall back to f35 if it doesn't work well enough.

Kalev
___
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

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

[Kevin Fenzi]

On Wed, Nov 25, 2020 at 02:18:45PM -, Wim Taymans wrote:
> So, the current sentiment is:

Well, of a few folks. :) 
 
> * provide an easy way to test in f33, either copr or with regular packages.
>- rawhide is a not a good place to get good testing anyway

It's likely more limited than f33 for sure, but it's still vaulable. 
I run rawhide on my main laptop and I know a number of QA folks do as
well when there is no branched. After f34 branches off rawhide, I know a
number of people who switch to it to test.

> * encourage people to test. Provide instructions on how to do this and how to
>leave feedback.
> * Carry this over to f34, probably with just the packages/easier switch.
> * propose permanent switch for f35
>   - it gets at least full cycle of testing (f34 + part of f33)
> * re-evaluate situation for f35 beta freeze to make a default switch.
> 
> Although a bit slower than expected, I guess more testing is good. It sounds
> like an acceptable plan to me.
> I'm not sure how it works, if spinoffs can/want to make an earlier switch?

I don't think we need to go this slow, unless we run into problems... 

If we run into problems in f34, we can just revert and try again for
f35. Of course that does assume that it's made easy to switch the
default back. 

So, for me personally, I think having a way to test in f33 would be
great and provide more feedback, but I think we should move ahead for
f34 unless there's blockers, in which case we revert back and try for
f35. 

kevin


signature.asc
Description: PGP signature
___
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

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

[Brandon Nielsen]

On 11/25/20 8:18 AM, Wim Taymans wrote:

So, the current sentiment is:

* provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
* encourage people to test. Provide instructions on how to do this and how to
leave feedback.
* Carry this over to f34, probably with just the packages/easier switch.
* propose permanent switch for f35
   - it gets at least full cycle of testing (f34 + part of f33)
* re-evaluate situation for f35 beta freeze to make a default switch.

Although a bit slower than expected, I guess more testing is good. It sounds
like an acceptable plan to me.
I'm not sure how it works, if spinoffs can/want to make an earlier switch?

Wim


My intention in stating my wishes this could be tested more widely was 
not to discourage this as a change for F34. I just hoped that since the 
change request states PipeWire is intended to work as a drop-in 
replacement for PulseAudio, that we could find a way to drop it in for 
at least Fedora 33 (copr, whatever), and hopefully maximize the test 
coverage. I figured more, easier, testing would make everybody more 
comfortable with inclusion in F34.


Even if it can't be an easy drop-in, I would at least like to see the 
documentation updated for how to hack it in, since apparently the 
symlink method is no longer the intended method.


No matter what, thank you so much for working so hard to improve the 
state of A/V in Linux!

___
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

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

[Alexander Bokovoy]

On ke, 25 marras 2020, Tomáš Popela wrote:

On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
wrote:


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.



Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
Chrome/Chromium?


Yes! And nothing works. It worked for me partially in F33 beta, not
anymore since F33 release. May be before that -- I did not track back
exact date when things changed to not work.

What I also see on this F33 instance is that mic input often disappears
from Chrome -- Firefox continues to see it but Chrome doesn't. And it is
even for a built-in mic on the laptop. In fact, I have now three mics
connected (one in Logitech's camera, one USB mic, one built-in) and
regularly get Chrome to not see any of the mics while GNOME Settings can
see them. Restart of Chrome helps for the first meeting done, then I
need to restart it again.

But even in Firefox no actual screen sharing happens. It doesn't
complain -- simply nothing gets out while everything is saying it
should.


--
/ 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

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

[Wim Taymans]

So, the current sentiment is:

* provide an easy way to test in f33, either copr or with regular packages.
   - rawhide is a not a good place to get good testing anyway
* encourage people to test. Provide instructions on how to do this and how to
   leave feedback.
* Carry this over to f34, probably with just the packages/easier switch.
* propose permanent switch for f35
  - it gets at least full cycle of testing (f34 + part of f33)
* re-evaluate situation for f35 beta freeze to make a default switch.

Although a bit slower than expected, I guess more testing is good. It sounds
like an acceptable plan to me.
I'm not sure how it works, if spinoffs can/want to make an earlier switch?

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

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

[Tomáš Popela]

On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy 
wrote:

> 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.
>

Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you
have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in
Chrome/Chromium?

Tom
___
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

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

[Vitaly Zaitsev via devel]

On 25.11.2020 13:36, Neal Gompa wrote:

We don't use API shims anymore for PulseAudio, we now replace the
daemon and reuse the original PulseAudio libraries.


This is not a complete replacement now. Running another daemon is not 
good for me.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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

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

[Neal Gompa]

On Wed, Nov 25, 2020 at 7:49 AM Alexander Bokovoy  wrote:
>
> 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?
>

That is a bug with GNOME. I have been using Plasma Wayland
screencasting perfectly with Plasma 5.20 on Fedora 33 with all three
this week. Could you please file a bug report against gnome-shell
about the issue?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Alexander Bokovoy]

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 

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

[Neal Gompa]

On Wed, Nov 25, 2020 at 6:06 AM Vitaly Zaitsev via devel
 wrote:
>
> On 24.11.2020 21:34, Neal Gompa wrote:
> > The packaging for PipeWire has been changing rapidly as the API shims
> > for PulseAudio changed from libraries to a replacement daemon, that's
> > why this is broken again.
>
> I see that they removed[1] the API shims. What about applications that
> require or even dlopen() the libpulse.so* shared libraries?
>
> They will crash if the pulseaudio package will be removed.
>
> [1]:
> https://src.fedoraproject.org/rpms/pipewire/c/306d51984ef5faf4ea455e6d385f0f1bae9a9ef1?branch=master
>

We don't use API shims anymore for PulseAudio, we now replace the
daemon and reuse the original PulseAudio libraries.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Vitaly Zaitsev via devel]

On 24.11.2020 21:34, Neal Gompa wrote:

The packaging for PipeWire has been changing rapidly as the API shims
for PulseAudio changed from libraries to a replacement daemon, that's
why this is broken again.


I see that they removed[1] the API shims. What about applications that 
require or even dlopen() the libpulse.so* shared libraries?


They will crash if the pulseaudio package will be removed.

[1]: 
https://src.fedoraproject.org/rpms/pipewire/c/306d51984ef5faf4ea455e6d385f0f1bae9a9ef1?branch=master


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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

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

[Vitaly Zaitsev via devel]

On 24.11.2020 22:33, Kevin Fenzi wrote:

Additionally, since it's a big change with a wide amount of workflows
and hardware and users expected, thats another reason to accept the
change for f34. It will then get testing up until the beta freeze... if
it's not ready then, it can be moved to f35 all the better for all the
testing it got in the early f34 cycle.


Yes-yes. Remember about the completely broken GCC 10 snapshot in Fedora 
32 with a lot of internal regressions. We shouldn't break the working 
audio configuration for end users.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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

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

[Tom Hughes via devel]

On 25/11/2020 10:47, Wim Taymans wrote:


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.


I think a key problem is that this is a feature that can only really
be tested in a desktop environment and not many people run rawhide on a
desktop, so if it's only testable in rawhide how much testing will it
really get.

That's probably why people are so keen to be able to test it in F33 or
to delay it for a further cycle.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

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

[Vitaly Zaitsev via devel]

On 24.11.2020 22:29, Kevin Fenzi wrote:

Barely over a month? I guess you are dropping all of this month, next
month and january? That seems a bit unfair.


Yes. We need at least 1 full Fedora release to test everything on real 
hardware. Optional PipeWire in F34 and default in F35.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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

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

[Wim Taymans]

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.

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.

> 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 

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

[Panu Matilainen]

On 11/24/20 9:17 PM, Neal Gompa wrote:

On Tue, Nov 24, 2020 at 2:07 PM Joël Krähemann  wrote:


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.


Indeed.

This discussion seems to be a proof that people can get used and 
attached to absolutely anything at all, such as three audio subsystems 
competing for the same resources being somehow a good thing.


The extent to which the multi-headed monster has been tamed over time is 
amazing, but on the production side there's never a point in time where 
you can truly forget, much less ignore the great divide underneath. All 
of which is just a constant unwanted distraction when you're trying to 
create music.


If something can unify that mess then halleluja.

- Panu -
___
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

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

[Dylan M Taylor]

> On Tue, Nov 24, 2020 at 3:30 PM Tom Seewald  
> Currently the PipeWire developers have been doing it by hand while
> they are developing the software. I have been going through and fixing
> things so that regular folks can do it semi-automatically.

Are there instructions available for this semi-automatic process to test this 
change now?
___
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

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

[Dylan M Taylor]

I'm very excited about this change and ultimately want to be able to test it 
out but it seems that there are still package dependency issues. How can I test 
this out on my end using the repos in their current state on either Fedora 33 
or Rawhide? I've got a few systems I can test on to see if there are any 
regressions, and don't mind running Rawhide to do some testing. Is there a 
write-up of how to test this that we can follow in the meantime until the 
packaging fixes land in Rawhide, or should end-users wait until Pipewire is 
packaged and set as default in a nightly Rawhide build? It seems like it would 
greatly benefit the Fedora project to get as many people trying this change out 
as possible.

--
Dylan Taylor
___
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

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

[Kevin Fenzi]

On Tue, Nov 24, 2020 at 05:27:31PM -0500, Solomon Peachy wrote:
> On Tue, Nov 24, 2020 at 01:33:57PM -0800, Kevin Fenzi wrote:
> > So, IMHO, relax, wait for change owners to make things testable, then
> > test and file bugs and we can see where we are. There's too many
> > unknowns right at this minute. 
> 
> So...you're saying that we should evaluate proposed changes, not as they 
> are currently written, but as they might be written at some unspcecified 
> later date.

no.

I am saying you should not look at a change and evaluate it like it's
landing in stable as soon as it's approved. There will be testing. There
will be bugs. If those bugs are serious enough there will be reverting
and trying again later. 

It's a 'Hey folks, we are going to try and do this, what do you think
about the approach' ? It sounds to me like everyone is fine with the
general idea, they just want lots of testing. Thats great. I would
definitely hope the change owners would also want that. I am pretty sure
however they thought things could be stablized by f34 or they wouldn't
have submitted it for f34. 

Anyhow, lets wait for the change owners to chime in and adjust their
change from the feedback so far.

kevin


signature.asc
Description: PGP signature
___
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

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

[Solomon Peachy]

On Tue, Nov 24, 2020 at 01:33:57PM -0800, Kevin Fenzi wrote:
> So, IMHO, relax, wait for change owners to make things testable, then
> test and file bugs and we can see where we are. There's too many
> unknowns right at this minute. 

So...you're saying that we should evaluate proposed changes, not as they 
are currently written, but as they might be written at some unspcecified 
later date.

(Which, oddly enough, is the same problem us naysayers have with the 
 actual change request...)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
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

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

[Kevin Fenzi]

On Mon, Nov 23, 2020 at 10:44:05AM -0600, Brandon Nielsen wrote:
> On 11/23/20 10:30 AM, Andreas Tunek wrote:
> > 
> > 
> > Den lör 21 nov. 2020 kl 15:31 skrev James Szinger  > >:
> > 
> > On Fri, 20 Nov 2020 18:35:19 -0600
> > Brandon Nielsen mailto:niels...@jetfuse.net>>
> > wrote:
> >  > If it has changed, it would be really great if pipewire-pulse could
> >  > make it into the F33 repos so it could be easily tested.
> > 
> > I agree.  I think new software should be available and testable on a
> > stable Fedora release before it becomes default.  I’m not ready to
> > have a rawhide install on real hardware to test something that’s not
> > ready yet.  I am especially wary of a change that requires new
> > software to be written between now and beta.
> > 
> > 
> > 
> > I think this is a way too high burden on new features. Testing in
> > rawhide should be enough. Something like pipewire is also pretty easy to
> > test in a Live system.
> > 
> > [Snip]
> > 
> 
> Easy to test basic things like sound works, headphones work, output device
> changing works. Much more difficult to test every audio use-case I use in a
> given day, week, month, because needs and uses change so much. Am I using my
> Bluetooth headphones today? A USB audio interface? Webcam? HDMI? Plus I work
> across different systems with almost entirely different hardware. I may be
> willing to run Rawhide on some of these systems, but most people probably
> won't.
> 
> I'm not saying this should necessarily be a mandate. But for something
> completely fundamental to how a lot of people use their systems, especially
> now, with such a wide array of hardware and uses, we should absolutely be
> pursuing the widest possible test coverage. And right now, the only answers
> are "it works in rawhide" and "it will be feature complete later".

Please do note that this week has US holidays in it and change owners
may be off away from computers taking time off. I don't think we should
be impatient on this... let them get a chance to respond rather than
everyone saying over and over they don't think it's ready and it's not
testable yet. 

Additionally, since it's a big change with a wide amount of workflows
and hardware and users expected, thats another reason to accept the
change for f34. It will then get testing up until the beta freeze... if
it's not ready then, it can be moved to f35 all the better for all the
testing it got in the early f34 cycle. 

So, IMHO, relax, wait for change owners to make things testable, then
test and file bugs and we can see where we are. There's too many
unknowns right at this minute. 

kevin


signature.asc
Description: PGP signature
___
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

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

[Kevin Fenzi]

On Sun, Nov 22, 2020 at 06:03:50PM -0500, Solomon Peachy wrote:
> On Sun, Nov 22, 2020 at 11:33:22AM -0800, Kevin Fenzi wrote:
> > It's supposed to be 'testable' by:
> > Change Checkpoint: Completion deadline (testable)   Tue 2021-02-09
> > and 100% code complete by:
> > Change Checkpoint: 100% Code Complete Deadline  Tue 2021-02-23
> 
> Given that Beta Freeze is 2021-03-16, barely over a month is frightfully 
> little time to adequately test something that has such an impact on the 
> end-user experience.

Barely over a month? I guess you are dropping all of this month, next
month and january? That seems a bit unfair. 

In any case if it's not ready by change checkpoint, it can/would be
reverted. Several big changes have had that happen to them, and it's
been for the better as they got all the testing up to that point and
were ready for the next cycle. 

kevin


signature.asc
Description: PGP signature
___
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

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

[Gary Buhrmaster]

On Tue, Nov 24, 2020 at 8:05 PM Neal Gompa  wrote:

> But that said, I would like to backport all the packaging changes to
> Fedora 33 too. It's not actually *hard* to do, it's just a matter of
> getting everyone to agree to get it to happen.

I think that being able to easily install/revert and run
pipewire as default in the F33 release will result in the
confidence that it is ready (or at least mostly ready)
and does not impact most of the Fedora community,
which would presumably make the decision to move
forward non-controversial.  And non-controversial
well tested (or testable) is presumably a goal.

I, for one, would be happy to run pipewire on
my daily F33 driver if I did not have to currently
jump through so many hoops to do so.
___
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

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

[Tom Seewald]

> Currently the PipeWire developers have been doing it by hand while
> they are developing the software. I have been going through and fixing
> things so that regular folks can do it semi-automatically.
> 
> The packaging for PipeWire has been changing rapidly as the API shims
> for PulseAudio changed from libraries to a replacement daemon, that's
> why this is broken again.

I know why it's currently broken, but that doesn't change the fact that this is 
being proposed before most people can assess the change. In fact the current 
amount of churn suggests that pipewire is still a ways off from stabilizing.
___
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

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

[Neal Gompa]

On Tue, Nov 24, 2020 at 3:30 PM Tom Seewald  wrote:
>
> > "Premature" is a weird term to use here, considering the whole point
> > of these things is to be able to do integration work in the first
> > place. And it's not like we can't revert the change before release if
> > it turns out to be problematic.
>
> Yes, premature as in proposing a huge change to the next version of Fedora 
> before ensuring current users can even test/evaluate said change. The fact 
> that there are packaging conflicts when installing pipewire-pulseaudio 
> strongly suggests that few people have actually been able to install and test 
> the package.

Currently the PipeWire developers have been doing it by hand while
they are developing the software. I have been going through and fixing
things so that regular folks can do it semi-automatically.

The packaging for PipeWire has been changing rapidly as the API shims
for PulseAudio changed from libraries to a replacement daemon, that's
why this is broken again.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Tom Seewald]

> "Premature" is a weird term to use here, considering the whole point
> of these things is to be able to do integration work in the first
> place. And it's not like we can't revert the change before release if
> it turns out to be problematic.

Yes, premature as in proposing a huge change to the next version of Fedora 
before ensuring current users can even test/evaluate said change. The fact that 
there are packaging conflicts when installing pipewire-pulseaudio strongly 
suggests that few people have actually been able to install and test the 
package.
___
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

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

[Neal Gompa]

On Tue, Nov 24, 2020 at 2:42 PM Tom Seewald  wrote:
>
> > 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.
>
> I really don't think a few test days are at all sufficient for such a 
> sweeping change. The fact users cannot easily test this on F33 makes it even 
> worse. I understand the desire for moving forward, but this change proposal 
> comes off as premature.

"Premature" is a weird term to use here, considering the whole point
of these things is to be able to do integration work in the first
place. And it's not like we can't revert the change before release if
it turns out to be problematic.

But that said, I would like to backport all the packaging changes to
Fedora 33 too. It's not actually *hard* to do, it's just a matter of
getting everyone to agree to get it to happen.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Tom Seewald]

> 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.

I really don't think a few test days are at all sufficient for such a sweeping 
change. The fact users cannot easily test this on F33 makes it even worse. I 
understand the desire for moving forward, but this change proposal comes off as 
premature.
___
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

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

[Joël Krähemann]

why not to allow pipes as sinks? Like "/dev/null".

On Tue, Nov 24, 2020 at 8:29 PM Reindl Harald (privat)  wrote:
>
>
>
> Am 24.11.20 um 20:26 schrieb Joël Krähemann:
> > What I can do with my software `gsequencer` all on top of ALSA.
>
> gsequencer is on the same layer the PA/pipewire
> case closed
>
> > * save or open Advanced Gtk+ Sequencer XML files with XPath support
> > * add or remove audio engines with adjustable audio channels and pads
> > * link channels with property dialog
> > * output panel, mixer, drum and matrix sequencer, soft synth and audio
> > file player
> > * piano roll with basic notation editing supporting copy & paste
> > * adjustable BPM
> > * LADSPA, DSSI and Lv2 support
> > * export to WAV, FLAC, OGG, MP3, MP4, MKV and WEBM
> > * multiple sinks/sources like JACK, ALSA, OSSv4, Pulseaudio, WASAPI
> > and Core-Audio
> > * automation editor with automation control and hide them to bypass
> > * waveform editor with one track per audio channel
> > * MIDI instrument playback
> > * Standard MIDI File import/export
> > * envelope editor per step sequencer or instrument
> > * OSC content format support and listening server using IPv4/IPv6 over 
> > UDP/TCP
> > * AGS-OSC-OVER-XMLRPC with libsoup-2.4 builtin XML login module for
> > basic HTTP authentication
> > * tic based system default max sync-rate upto 1000 Hz
> >
> > On Tue, Nov 24, 2020 at 8:16 PM Reindl Harald (privat)  
> > wrote:
> >>
> >>
> >>
> >> Am 24.11.20 um 20:06 schrieb Joël Krähemann:
>  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
> >>
> >> who is talking about YouTube?
> >
> > This was just an example if you want to mix something while doing
> > audio production.
> >
> >>
> >>> What do you want to mix?
> >>
> >> just hear different audio-sources at the same time?
> >>
> >
> > In `gsequencer` you can even configure multiple sound cards for
> > playback or capture. It actually works quite well.
> >
> >>> Might be for some exotic JACK setup
> >>
> >> what is exotic in the simple fact that one has running sound from
> >> different sources no matter jackaudio or not?
> >>
> >
> > Again, I am talking about producing things like songs or a screencast.
> >
> >> the problem with pure alsa is that typically *one* software claims the
> >> audio device and that's it while in many workloads you just have running
> >> more than one sioruce no matter if they are all muted except one or
> >> really play at the same time
> >
> > You basically ignore my arguments on latency.
> >
> > Stop alienating me and mixing unrelated things ...
> >
> > This is your very own sight of things, you should broaden your
> > spectrum.
> >
> > Further, you can mix it all in GSequencer in any way you want to. Like
> > bundling different JACK sources.
> >
> > The low latency MIDI experience will burst your experience on top of
> > ALSA.
___
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

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

[Joël Krähemann]

Hi,

What I can do with my software `gsequencer` all on top of ALSA.

* save or open Advanced Gtk+ Sequencer XML files with XPath support
* add or remove audio engines with adjustable audio channels and pads
* link channels with property dialog
* output panel, mixer, drum and matrix sequencer, soft synth and audio
file player
* piano roll with basic notation editing supporting copy & paste
* adjustable BPM
* LADSPA, DSSI and Lv2 support
* export to WAV, FLAC, OGG, MP3, MP4, MKV and WEBM
* multiple sinks/sources like JACK, ALSA, OSSv4, Pulseaudio, WASAPI
and Core-Audio
* automation editor with automation control and hide them to bypass
* waveform editor with one track per audio channel
* MIDI instrument playback
* Standard MIDI File import/export
* envelope editor per step sequencer or instrument
* OSC content format support and listening server using IPv4/IPv6 over UDP/TCP
* AGS-OSC-OVER-XMLRPC with libsoup-2.4 builtin XML login module for
basic HTTP authentication
* tic based system default max sync-rate upto 1000 Hz

On Tue, Nov 24, 2020 at 8:16 PM Reindl Harald (privat)  wrote:
>
>
>
> Am 24.11.20 um 20:06 schrieb Joël Krähemann:
> >> 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
>
> who is talking about YouTube?

This was just an example if you want to mix something while doing
audio production.

>
> > What do you want to mix?
>
> just hear different audio-sources at the same time?
>

In `gsequencer` you can even configure multiple sound cards for
playback or capture. It actually works quite well.

> > Might be for some exotic JACK setup
>
> what is exotic in the simple fact that one has running sound from
> different sources no matter jackaudio or not?
>

Again, I am talking about producing things like songs or a screencast.

> the problem with pure alsa is that typically *one* software claims the
> audio device and that's it while in many workloads you just have running
> more than one sioruce no matter if they are all muted except one or
> really play at the same time

You basically ignore my arguments on latency.

Stop alienating me and mixing unrelated things ...

This is your very own sight of things, you should broaden your
spectrum.

Further, you can mix it all in GSequencer in any way you want to. Like
bundling different JACK sources.

The low latency MIDI experience will burst your experience on top of
ALSA.

cheers,
Joël
___
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

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

[Tom Seewald]

> Dne 24. 11. 20 v 15:15 Vít Ondruch napsal(a):
> 
> 
> Just FTR, this is the situation on Rawhide:
> 
> 
> ~~~
> 
> $ sudo dnf swap pulseaudio pipewire-pulseaudio
> Last metadata expiration check: 0:03:54 ago on Mon Nov 23 23:14:58 2020.
> Error:
>   Problem 1: problem with installed package 
> pulseaudio-module-x11-13.99.3-1.fc34.x86_64
>    - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires 
> libprotocol-native.so()(64bit), but none of the providers can be installed
>    - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires 
> libpulsecore-13.99.so()(64bit), but none of the providers can be installed
>    - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires 
> pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be 
> installed
>    - conflicting requests
>   Problem 2: problem with installed package 
> pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64
>    - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires 
> libpulsecore-13.99.so()(64bit), but none of the providers can be installed
>    - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires 
> pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be 
> installed
>    - package pipewire-pulseaudio-0.3.16-3.fc34.x86_64 conflicts with 
> pulseaudio provided by pulseaudio-13.99.3-1.fc34.x86_64
>    - conflicting requests
> (try to add '--allowerasing' to command line to replace conflicting 
> packages or '--skip-broken' to skip uninstallable packages)
> 
> 
> $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing
> 
> Last metadata expiration check: 0:04:54 ago on Mon Nov 23 23:14:58 2020.
> Error:
>   Problem: The operation would result in removing the following 
> protected packages: gnome-shell
> (try to add '--skip-broken' to skip uninstallable packages)
> 
> 
> $ sudo dnf remove pulseaudio-module-x11
> Dependencies resolved.
> ===
>   Package Architecture Version 
> Repository Size
> ===
> Removing:
>   pulseaudio-module-x11 x86_64 13.99.3-1.fc34 
> @rawhide   78 k
> 
> Transaction Summary
> ===
> Remove  1 Package
> 
> Freed space: 78 k
> Is this ok [y/N]: ^COperation aborted.
> 
> $ sudo dnf remove pulseaudio-module-bluetooth
> 
> Error:
>   Problem: The operation would result in removing the following 
> protected packages: gnome-shell
> (try to add '--skip-broken' to skip uninstallable packages)
> 
> ~~~

I've filed a bug report for this: 
https://bugzilla.redhat.com/show_bug.cgi?id=1900876

I think this definitely needs to be resolved quickly if this proposal is to go 
forward, otherwise the already small testing window will be even more narrow.
___
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

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

[Neal Gompa]

On Tue, Nov 24, 2020 at 2:07 PM Joël Krähemann  wrote:
>
> Hi,
>
> This is bad.
>
> On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa  wrote:
> >
> > On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann  
> > 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@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

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

[Joël Krähemann]

Hi,

This is bad.

On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa  wrote:
>
> On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann  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.

>
> 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.

>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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
___
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

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

[Vitaly Zaitsev via devel]

On 24.11.2020 15:31, Vít Ondruch wrote:

So I wonder what libraries are you referring to?


libpulse.so*, but they we remove from the spec by this[1] commit.

[1]: 
https://src.fedoraproject.org/rpms/pipewire/c/306d51984ef5faf4ea455e6d385f0f1bae9a9ef1?branch=master


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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

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

[Vít Ondruch]

Dne 24. 11. 20 v 15:22 Vitaly Zaitsev via devel napsal(a):

On 24.11.2020 15:15, Vít Ondruch wrote:
I think it would be simple enough if there was not the explicit 
conflict with pulse audio [1]. The instruction could be "Disable PA 
service and install PW".


Absolutely impossible. They provides libraries with the same name.



It was already said in this thread previously:


~~~

$ sudo dnf repoquery -l pipewire-pulseaudio
Last metadata expiration check: 0:34:19 ago on Tue Nov 24 14:55:40 2020.
/usr/bin/pipewire-pulse
/usr/lib/.build-id
/usr/lib/.build-id/50
/usr/lib/.build-id/50/e366932de35c2ce639b0d4a768e368c5282b1a
/usr/lib/systemd/user/pipewire-pulse.service
/usr/lib/systemd/user/pipewire-pulse.socket
~~~

So I wonder what libraries are you referring to?

I think that these services would compete for the same socket, but they 
don't conflict IMO.




Vít




OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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

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

[Vít Ondruch]

Dne 24. 11. 20 v 15:15 Vít Ondruch napsal(a):


Dne 22. 11. 20 v 13:07 Dominique Martinet napsal(a):

Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020:

On 22.11.2020 12:36, Dominique Martinet wrote:
That removes stuff like gnome-shell.. (as dependent packages of 
pulseaudio)

Perhaps a missing provide?

Some packages directly depends on the pulseaudio package instead of
the required libraries:

That's not gnome-shell's case.

$ rpm -q --requires gnome-shell | grep pulse
libpulse-mainloop-glib.so.0()(64bit)
libpulse-mainloop-glib.so.0(PULSE_0)(64bit)
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)(64bit)

$ dnf -C repoquery --whatprovides 'libpulse.so.0(PULSE_0)(64bit)'
Last metadata expiration check: 0:09:40 ago on Sun 22 Nov 2020 
12:51:10 CET.

pulseaudio-libs-0:13.99.2-1.fc33.x86_64
$ dnf -C repoquery --whatprovides 
'libpulse-mainloop-glib.so.0(PULSE_0)(64bit)'
Last metadata expiration check: 0:09:53 ago on Sun 22 Nov 2020 
12:51:10 CET.

pulseaudio-libs-glib2-0:13.99.2-1.fc33.x86_64


or, put the other way around:
$ dnf -C repoquery --provides pulseaudio-libs
Last metadata expiration check: 0:10:47 ago on Sun 22 Nov 2020 
12:51:10 CET.

config(pulseaudio-libs) = 13.99.2-1.fc33
libpulse-simple.so.0
libpulse-simple.so.0()(64bit)
libpulse-simple.so.0(PULSE_0)
libpulse-simple.so.0(PULSE_0)(64bit)
libpulse.so.0
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)
libpulse.so.0(PULSE_0)(64bit)
libpulsecommon-13.99.so
libpulsecommon-13.99.so()(64bit)
libpulsedsp.so
libpulsedsp.so()(64bit)
pulseaudio-libs = 13.99.2-1.fc33
pulseaudio-libs(x86-32) = 13.99.2-1.fc33
pulseaudio-libs(x86-64) = 13.99.2-1.fc33

$ dnf -C repoquery --provides pipewire-pulseaudio
Last metadata expiration check: 0:11:16 ago on Sun 22 Nov 2020 
12:51:10 CET.

pipewire-pulseaudio = 0.3.13-4.fc33
pipewire-pulseaudio = 0.3.15-2.fc33
pipewire-pulseaudio = 0.3.16-2.fc33
pipewire-pulseaudio(x86-32) = 0.3.13-4.fc33
pipewire-pulseaudio(x86-32) = 0.3.15-2.fc33
pipewire-pulseaudio(x86-64) = 0.3.13-4.fc33
pipewire-pulseaudio(x86-64) = 0.3.15-2.fc33
pipewire-pulseaudio(x86-64) = 0.3.16-2.fc33
pulseaudio-libs
pulseaudio-libs-glib2

apparently providing pulseaudio-libs / pulseaudio-libs-glib2 does not
transitively mean they provide libpulse.so/libpulse-mainloop-glib.so ?


Or is the thing just broken atm? I just downloaded the latest and it
only contains the server side part (systemd user service/socket for
pipewire-pulse):
$ rpm -qpl pipewire-pulseaudio-0.3.16-2.fc33.x86_64.rpm
/usr/lib/systemd/user/pipewire-pulse.service
/usr/lib/systemd/user/pipewire-pulse.socket


Yet tries to provide the client (pulseaudio-libs*).. that's just wrong?!



I think it would be simple enough if there was not the explicit 
conflict with pulse audio [1]. The instruction could be "Disable PA 
service and install PW".


Better solution would be if pulseaudio-module-bluetooth did not depend 
on pulseaudio.



Just FTR, this is the situation on Rawhide:


~~~

$ sudo dnf swap pulseaudio pipewire-pulseaudio
Last metadata expiration check: 0:03:54 ago on Mon Nov 23 23:14:58 2020.
Error:
 Problem 1: problem with installed package 
pulseaudio-module-x11-13.99.3-1.fc34.x86_64
  - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires 
libprotocol-native.so()(64bit), but none of the providers can be installed
  - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires 
libpulsecore-13.99.so()(64bit), but none of the providers can be installed
  - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires 
pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be 
installed

  - conflicting requests
 Problem 2: problem with installed package 
pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64
  - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires 
libpulsecore-13.99.so()(64bit), but none of the providers can be installed
  - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires 
pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be 
installed
  - package pipewire-pulseaudio-0.3.16-3.fc34.x86_64 conflicts with 
pulseaudio provided by pulseaudio-13.99.3-1.fc34.x86_64

  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)



$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing

Last metadata expiration check: 0:04:54 ago on Mon Nov 23 23:14:58 2020.
Error:
 Problem: The operation would result in removing the following 
protected packages: gnome-shell

(try to add '--skip-broken' to skip uninstallable packages)


$ sudo dnf remove pulseaudio-module-x11
Dependencies resolved.
===
 Package Architecture Version 
Repository Size

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

[Neal Gompa]

On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann  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.

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.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Justin W. Flory]

Sounds to me like good opt-out documentation is in order. 


\--
Cheers,
Justin W. Flory (he/him)
https://jwf.io
Sent from ProtonMail mobile




\ Original Message 
On Nov 24, 2020, 09:19, Joël Krähemann < jkraehem...@gmail.com> 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

Didn't look at pipewire, yet. Finally, please consider to shutdown the
process completely as desired.

publickey - EmailAddress(s=foss@jwf.io) - 0x570E854F.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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

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

[Vitaly Zaitsev via devel]

On 24.11.2020 15:15, Vít Ondruch wrote:
I think it would be simple enough if there was not the explicit conflict 
with pulse audio [1]. The instruction could be "Disable PA service and 
install PW".


Absolutely impossible. They provides libraries with the same name.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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

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

[Joël Krähemann]

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.

regards,
Joël
___
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

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

[Vít Ondruch]

Dne 22. 11. 20 v 13:07 Dominique Martinet napsal(a):

Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020:

On 22.11.2020 12:36, Dominique Martinet wrote:

That removes stuff like gnome-shell.. (as dependent packages of pulseaudio)
Perhaps a missing provide?

Some packages directly depends on the pulseaudio package instead of
the required libraries:

That's not gnome-shell's case.

$ rpm -q --requires gnome-shell | grep pulse
libpulse-mainloop-glib.so.0()(64bit)
libpulse-mainloop-glib.so.0(PULSE_0)(64bit)
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)(64bit)

$ dnf -C repoquery --whatprovides 'libpulse.so.0(PULSE_0)(64bit)'
Last metadata expiration check: 0:09:40 ago on Sun 22 Nov 2020 12:51:10 CET.
pulseaudio-libs-0:13.99.2-1.fc33.x86_64
$ dnf -C repoquery --whatprovides 'libpulse-mainloop-glib.so.0(PULSE_0)(64bit)'
Last metadata expiration check: 0:09:53 ago on Sun 22 Nov 2020 12:51:10 CET.
pulseaudio-libs-glib2-0:13.99.2-1.fc33.x86_64


or, put the other way around:
$ dnf -C repoquery --provides pulseaudio-libs
Last metadata expiration check: 0:10:47 ago on Sun 22 Nov 2020 12:51:10 CET.
config(pulseaudio-libs) = 13.99.2-1.fc33
libpulse-simple.so.0
libpulse-simple.so.0()(64bit)
libpulse-simple.so.0(PULSE_0)
libpulse-simple.so.0(PULSE_0)(64bit)
libpulse.so.0
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)
libpulse.so.0(PULSE_0)(64bit)
libpulsecommon-13.99.so
libpulsecommon-13.99.so()(64bit)
libpulsedsp.so
libpulsedsp.so()(64bit)
pulseaudio-libs = 13.99.2-1.fc33
pulseaudio-libs(x86-32) = 13.99.2-1.fc33
pulseaudio-libs(x86-64) = 13.99.2-1.fc33

$ dnf -C repoquery --provides pipewire-pulseaudio
Last metadata expiration check: 0:11:16 ago on Sun 22 Nov 2020 12:51:10 CET.
pipewire-pulseaudio = 0.3.13-4.fc33
pipewire-pulseaudio = 0.3.15-2.fc33
pipewire-pulseaudio = 0.3.16-2.fc33
pipewire-pulseaudio(x86-32) = 0.3.13-4.fc33
pipewire-pulseaudio(x86-32) = 0.3.15-2.fc33
pipewire-pulseaudio(x86-64) = 0.3.13-4.fc33
pipewire-pulseaudio(x86-64) = 0.3.15-2.fc33
pipewire-pulseaudio(x86-64) = 0.3.16-2.fc33
pulseaudio-libs
pulseaudio-libs-glib2

apparently providing pulseaudio-libs / pulseaudio-libs-glib2 does not
transitively mean they provide libpulse.so/libpulse-mainloop-glib.so ?


Or is the thing just broken atm? I just downloaded the latest and it
only contains the server side part (systemd user service/socket for
pipewire-pulse):
$ rpm -qpl pipewire-pulseaudio-0.3.16-2.fc33.x86_64.rpm
/usr/lib/systemd/user/pipewire-pulse.service
/usr/lib/systemd/user/pipewire-pulse.socket


Yet tries to provide the client (pulseaudio-libs*).. that's just wrong?!



I think it would be simple enough if there was not the explicit conflict 
with pulse audio [1]. The instruction could be "Disable PA service and 
install PW".


Better solution would be if pulseaudio-module-bluetooth did not depend 
on pulseaudio.


Now is PW not installable unless doing some hacks :(


Vít


[1] 
https://src.fedoraproject.org/rpms/pipewire/blob/master/f/pipewire.spec#_193






(unrelated: I'm getting pavucontrol segfaults with pipewire-pulse server, just
opened a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1900339
)


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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

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

[James Szinger]

On Mon, 23 Nov 2020 17:30:51 +0100
Andreas Tunek  wrote:

> Den lör 21 nov. 2020 kl 15:31 skrev James Szinger
> :
> 
> > On Fri, 20 Nov 2020 18:35:19 -0600
> > Brandon Nielsen  wrote:  
> > > If it has changed, it would be really great if pipewire-pulse
> > > could make it into the F33 repos so it could be easily tested.  
> >
> > I agree.  I think new software should be available and testable on a
> > stable Fedora release before it becomes default.  I’m not ready to
> > have a rawhide install on real hardware to test something that’s not
> > ready yet.  I am especially wary of a change that requires new
> > software to be written between now and beta.
> >
> >  
> 
> I think this is a way too high burden on new features. Testing in
> rawhide should be enough. Something like pipewire is also pretty easy
> to test in a Live system.

There is difference between having a feature available and making it the
default.

I fully support have pipewire replacing pulseaudio as an optional
feature.  I am opposed to making it the default without adequate
testing.  I am not even proposing a 'no regression' rule.  I am just
asking for extensive testing and real-world use, so that an informed
decision can be made about the defaults.  The proposed testing is
not enough.

Jim
___
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

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

[Luya Tshimbalanga]

On 2020-11-20 2:31 p.m., Naheem Zaffar wrote:



On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen > wrote:


On 11/20/20 1:28 PM, Dominique Martinet wrote:
> Ben Cotton wrote on Fri, Nov 20, 2020:
l the pipewire-pulse library (which
>> removes the pulseaudio package).
>
> Took me some time to figure out how to test:

[Snip]

Me too.

I think for current F33 / Rawhide you're expected to create some
symlinks manually:
https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165



I don't think this is the the correct way any longer. Lib-Pulse was 
AFAIK the initially planned drop-in replacement for pulseaudio. This 
has since been deprecated. Pipewire-Pulse AFAIK provides a separate 
pulseaudio server. I dont think it needs any linking, other than 
software activation.




Pipewire-pulse is not packaged yet. It will be great to get it available 
for Fedora 33 for testing purpose.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

___
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

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

[Brandon Nielsen]

On 11/23/20 11:48 AM, Adam Williamson wrote:

On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote:

On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:

On 11/20/20 5:26 PM, Ben Cotton wrote:


The pulseaudio package will be uninstalled and pipewire-pulse will be installed.

pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34

IMO, this alone disqualifies this plan.

Fedora should be a stable end-user distro and not a testing site for eager
devs to test their immature and incomplete works.


   I think Fedora should establish strong "no regressions" rule when
replacing system software like this.  PulseAudio has had 15 years of
development, features and fixes.  It is hard to believe pipewire is as
capable as a replacement now.


I disagree. This would be incompatible with the "First" foundation.

If we'd had a "no regressions" rule for pre-PA audio, we'd probably
never have landed PA, or not for years. Are things on the whole better
since we did? I'd say yes.

Will our first release with pipewire probably have some bugs that
constitute regressions from the previous audio setup? Almost certainly.
Especially given the sheer amounts of stuff people do - see your config
below - I think we'd find it difficult to have a "no regressions" rule
and still be Fedora. Part of Fedora's job is to adopt new things and
shake some of the initial bugs out of them.


   Of course we would need to start with collecting the use cases, and
this will be different for every user.  For example, I frequently use my
laptop with 3 sound devices present: built-in speakers, speakers
connected to USB-C dock and bluetooth headphones*.  I use pavucontrol to
route applications to proper output/input and I expect this to work the
same with PW.  This is important to me.


Did that all work with the first Fedora with PA in it? I bet not. Would
we have as capable a PA today if Fedora hadn't taken the leap to
include PA? Probably not.

>

[Snip]


PulseAudio wasn't necessarily purporting to be a drop-in replacement for 
Alsa. It seems like if PipeWire really is going to be swappable like the 
change text notes[0], we should be looking at this as a rare opportunity 
to get really widespread testing with a potentially majorly breaking 
change by offering the ability to easily swap it in and test in already 
released versions. That way we could be "first" and "battle hardened" at 
the same time.


Unfortunately, as noted elsewhere in this thread, there really isn't a 
way to test outside of Rawhide currently[1][2][3]. It seems like the 
packages are there and should work, but might not[4]?


As I've mentioned elsewhere, I'm not saying handling changes like this 
should be mandated[5], or even required in this specific case, or 
elsewhere. But I think there would be less pushback to the change if 
this was the course of action.


[0] - "This proposal is to replace the PulseAudio daemon with a 
functionally compatible implementation based on PipeWire. This means 
that all existing clients using the PulseAudio client library will 
continue to work as before, as well as applications shipped as Flatpak."
[1] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KNQXW2XNVS4KVGHBONNWIUWXBSCRBGRV/
[2] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LITC357UASWMUBFCVDHOPOG2B4W3VMI6/
[3] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RLCQAMCUASZ764LQ2YQ7PXYKNZVVKJX7/
[4] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4OZXC2FSFPOZ5EJS4M5YNCEADIAHOGNF/
[5] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E262AGSRXKUZ5SYR6IP3TQ4JJMBDWKGS/

___
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

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

[Solomon Peachy]

On Mon, Nov 23, 2020 at 09:48:56AM -0800, Adam Williamson wrote:
> If we'd had a "no regressions" rule for pre-PA audio, we'd probably
> never have landed PA, or not for years. Are things on the whole better
> since we did? I'd say yes.

You are correct; however the crucial difference between then and now is 
that PulseAudio was installable (and therefore testable) in Fedora 7 
prior to Fedora 8 making it the default.

That is not the case with PipeWire today.

> QA folks, this is definitely a Change that (if approved) we should do a
> Test Day (or several) for, and probably one that could use help with a
> better test plan. Do we have any domain experts who'd like to volunteer
> to work on that? Thanks!

If "Test Day" requires running rawhide (or booting a LiveUSB image) then 
I'm not going to be able to do meanigful testing with my actual desktop 
environment and applications.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
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

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

[Adam Williamson]

On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote:
> On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
> > On 11/20/20 5:26 PM, Ben Cotton wrote:
> > 
> > > The pulseaudio package will be uninstalled and pipewire-pulse will be 
> > > installed.
> > > 
> > > pipewire-pulse does not yet implement all the features of pulseaudio
> > > but it is expected that
> > > comparable functionality will be implemented later. Most notable
> > > features that are likely
> > > not going to be available for fedora 34
> > IMO, this alone disqualifies this plan.
> > 
> > Fedora should be a stable end-user distro and not a testing site for eager
> > devs to test their immature and incomplete works.
> 
>   I think Fedora should establish strong "no regressions" rule when
> replacing system software like this.  PulseAudio has had 15 years of
> development, features and fixes.  It is hard to believe pipewire is as
> capable as a replacement now.

I disagree. This would be incompatible with the "First" foundation.

If we'd had a "no regressions" rule for pre-PA audio, we'd probably
never have landed PA, or not for years. Are things on the whole better
since we did? I'd say yes.

Will our first release with pipewire probably have some bugs that
constitute regressions from the previous audio setup? Almost certainly.
Especially given the sheer amounts of stuff people do - see your config
below - I think we'd find it difficult to have a "no regressions" rule
and still be Fedora. Part of Fedora's job is to adopt new things and
shake some of the initial bugs out of them.

>   Of course we would need to start with collecting the use cases, and
> this will be different for every user.  For example, I frequently use my
> laptop with 3 sound devices present: built-in speakers, speakers
> connected to USB-C dock and bluetooth headphones*.  I use pavucontrol to
> route applications to proper output/input and I expect this to work the
> same with PW.  This is important to me.

Did that all work with the first Fedora with PA in it? I bet not. Would
we have as capable a PA today if Fedora hadn't taken the leap to
include PA? Probably not.

>   On the other hand, I do not use AC3 passthrough when watching movies
> and I'm not so much interested in power saving through dynamic
> latency/timers adjustment and suspending outputs.  If this ceased to
> work, _I_ wouldn't notice.  But for someone this may be crucial. The
> same for equalizer modules. Or volume ramp up. Or multiple device
> combining. And so on.

Yes, and on and on and on and on and on and on and on...

>   Right now "How to test" section of Change Proposal contains only very
> rudimentary cases like "check if rhythmbox plays".  This is not enough
> when replacing as potent software as PulseAudio.

*This*, though, I tend to agree with. "How to test" sections do tend to
be mailed in. It would be good to cover at least a range of commonly
used configurations here.

QA folks, this is definitely a Change that (if approved) we should do a
Test Day (or several) for, and probably one that could use help with a
better test plan. Do we have any domain experts who'd like to volunteer
to work on that? Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
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

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

[Roberto Ragusa]

On 11/23/20 5:23 PM, stan via devel wrote:

On Sun, 22 Nov 2020 15:47:04 +0100
Andy Mender  wrote:


Is ALSA still a valid use case? I thought ALSA support was phased out
from most relevant software?


It is for me.  I run some audio software that I do not want interrupted
while it is running.  So, I use pavucontrol to turn it off to pulse and
make it available only to alsa.  Then, I can directly configure, send
commands to, and use the sound device, ignored by pulse.  As near as I
can tell, it is still available in audacity, as well.

My use case for pure alsa is video grabbing of VHS tapes.
Sound is captured at alsa level, I do not want any pulseaudio in the middle.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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

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

[Tomasz Torcz]

On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
> On 11/20/20 5:26 PM, Ben Cotton wrote:
> 
> > The pulseaudio package will be uninstalled and pipewire-pulse will be 
> > installed.
> >
> > pipewire-pulse does not yet implement all the features of pulseaudio
> > but it is expected that
> > comparable functionality will be implemented later. Most notable
> > features that are likely
> > not going to be available for fedora 34
> IMO, this alone disqualifies this plan.
> 
> Fedora should be a stable end-user distro and not a testing site for eager
> devs to test their immature and incomplete works.

  I think Fedora should establish strong "no regressions" rule when
replacing system software like this.  PulseAudio has had 15 years of
development, features and fixes.  It is hard to believe pipewire is as
capable as a replacement now.

  Of course we would need to start with collecting the use cases, and
this will be different for every user.  For example, I frequently use my
laptop with 3 sound devices present: built-in speakers, speakers
connected to USB-C dock and bluetooth headphones*.  I use pavucontrol to
route applications to proper output/input and I expect this to work the
same with PW.  This is important to me.

  On the other hand, I do not use AC3 passthrough when watching movies
and I'm not so much interested in power saving through dynamic
latency/timers adjustment and suspending outputs.  If this ceased to
work, _I_ wouldn't notice.  But for someone this may be crucial. The
same for equalizer modules. Or volume ramp up. Or multiple device
combining. And so on.

  Right now "How to test" section of Change Proposal contains only very
rudimentary cases like "check if rhythmbox plays".  This is not enough
when replacing as potent software as PulseAudio.


* - for some BT codecs I need pulseaudio-module-bluetooth-freeworld

-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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

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

[Brandon Nielsen]

On 11/23/20 10:30 AM, Andreas Tunek wrote:



Den lör 21 nov. 2020 kl 15:31 skrev James Szinger >:


On Fri, 20 Nov 2020 18:35:19 -0600
Brandon Nielsen mailto:niels...@jetfuse.net>>
wrote:
 > If it has changed, it would be really great if pipewire-pulse could
 > make it into the F33 repos so it could be easily tested.

I agree.  I think new software should be available and testable on a
stable Fedora release before it becomes default.  I’m not ready to
have a rawhide install on real hardware to test something that’s not
ready yet.  I am especially wary of a change that requires new
software to be written between now and beta.



I think this is a way too high burden on new features. Testing in 
rawhide should be enough. Something like pipewire is also pretty easy to 
test in a Live system.


[Snip]



Easy to test basic things like sound works, headphones work, output 
device changing works. Much more difficult to test every audio use-case 
I use in a given day, week, month, because needs and uses change so 
much. Am I using my Bluetooth headphones today? A USB audio interface? 
Webcam? HDMI? Plus I work across different systems with almost entirely 
different hardware. I may be willing to run Rawhide on some of these 
systems, but most people probably won't.


I'm not saying this should necessarily be a mandate. But for something 
completely fundamental to how a lot of people use their systems, 
especially now, with such a wide array of hardware and uses, we should 
absolutely be pursuing the widest possible test coverage. And right now, 
the only answers are "it works in rawhide" and "it will be feature 
complete later".

___
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

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

[Andreas Tunek]

Den lör 21 nov. 2020 kl 15:31 skrev James Szinger :

> On Fri, 20 Nov 2020 18:35:19 -0600
> Brandon Nielsen  wrote:
> > If it has changed, it would be really great if pipewire-pulse could
> > make it into the F33 repos so it could be easily tested.
>
> I agree.  I think new software should be available and testable on a
> stable Fedora release before it becomes default.  I’m not ready to
> have a rawhide install on real hardware to test something that’s not
> ready yet.  I am especially wary of a change that requires new
> software to be written between now and beta.
>
>

I think this is a way too high burden on new features. Testing in rawhide
should be enough. Something like pipewire is also pretty easy to test in a
Live system.

Best regards
Andreas



> Remember, there was great anger and frustration when pulseaudio became
> the default before it was ready (IMHO).  It has improved a lot since
> then.  Please learn from them and make it easy for volunteers to test
> this with real use before breaking everyone’s sound.  I have a few
> things I want to try beyond what is in the how-to-test section.
>
> Please provide simple instructions on how to test for F33/32 or defer
> the change until F35.  Overall, pipewire sounds very promising; I just
> want to be sure it is ready.
>
> Jim
> ___
> 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
>
___
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

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

[stan via devel]

On Sun, 22 Nov 2020 15:47:04 +0100
Andy Mender  wrote:

> Is ALSA still a valid use case? I thought ALSA support was phased out
> from most relevant software?

It is for me.  I run some audio software that I do not want interrupted
while it is running.  So, I use pavucontrol to turn it off to pulse and
make it available only to alsa.  Then, I can directly configure, send
commands to, and use the sound device, ignored by pulse.  As near as I
can tell, it is still available in audacity, as well.

alsa is going nowhere since it is the interface to the hardware that
every other sound application depends on.  It is mature so it should
take very little maintenance to allow it to remain.
___
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

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

[edmond pilon]

I  have  installed pipewire-pulseaudio,  pipewire-libjack  pipewire-alsa ( 
pipewire 3.16  rawhide ).
Pulseaudio is removed   but nevertheless i have no issue actually. Sounds and 
software (pavucontrol ..etc) are working.
Only  one of my  mixers (plasma-pa) is  removed because of a pulseaudio 
dependency and needs to be rebuild.
 Sorry for my english.
___
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

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

[Solomon Peachy]

On Sun, Nov 22, 2020 at 07:20:20PM +, Gargoyle wrote:
> Nope. I couldn't disagree more. If there's a long tail of unmaintained
> software without commercial gains, then it should be left to die in the
> great software graveyard. Feel free to keep a copy of F32 kicking around for
> when you want to run it, but it should not be a reason to stifle progress.

So "Progress" means "Proposing to force everyone to use software that 
doesn't even work right now, and won't be ready until (at best) a month 
before the F34 Beta Freeze"

...Right...

Maybe while we're at it we should make Fedora require AVX2, because 
supporting those old CPUs is clearly "stifiling progress"?

Nobody is saying "never" to pipewire; we are saying "not now", because 
*it can't be tested right now* and won't likely be ready for actual 
testing until (optimisticly) about a month before the F34 beta freeze.

To say nothing for the time needed to actually find and fix issues on 
the long tail of deployed hardware and software. That, to me, is a 
glaring sign that this proposal is _very_ premature.

Fedora took years before switching to Wayland by default, and that was 
something that had a far greater upside than this does.

> Yes. And Microsoft get paid a lot of money to build it that way. There's a
> commercial gain to be had justifying employing people to keep that
> compatibility going.

Are you volunteering to do all of this coding/porting yourself?  If not, 
why do you seem to believe that developer time is without cost?

I hate to break it to you, but 98% of what is in Fedora is "without 
commercial gains" -- and I can promise you that one year is nowhere near 
enough time to fix up everything that Fedora ships, much less the long 
tail of F/OSS that isn't packaged.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
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