Skip to content
This repository has been archived by the owner on Jan 25, 2021. It is now read-only.

Pipewire coming to Fedora #147

Open
gombosg opened this issue Dec 16, 2020 · 10 comments
Open

Pipewire coming to Fedora #147

gombosg opened this issue Dec 16, 2020 · 10 comments
Assignees

Comments

@gombosg
Copy link

gombosg commented Dec 16, 2020

Hi @EHfive! I wanted to have a conversation here about pipewire.
It is coming to Fedora 34 next spring.
https://fedoraproject.org/wiki/Changes/DefaultPipeWire

Now, I think there are quite a lot of Fedora users for this package.
I'm unable to test Pipewire yet (I use F33 and can't install it properly).

Do you know how this package interacts with pipewire-pulseaudio?
Do you know if pipewire supports aptX already?

I heard that https://github.com/pali/libopenaptx is compatible with pipewire, so maybe I will start packaging it.

The basic goal is that Fedora users should be able to use aptX, LDAC, AAC codecs on Bluetooth with pipewire, too, if that's possible.

@gombosg gombosg added the bug Something isn't working label Dec 16, 2020
@soredake
Copy link

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

@EHfive
Copy link
Owner

EHfive commented Dec 16, 2020

Do you know if pipewire supports aptX already?

aptX, LDAC (https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/341) is working on PipeWire . aptX HD still have problems. AAC support has not been finished yet.

Do you know how this package interacts with pipewire-pulseaudio?

Basically pipewire-pulseaudio is just a meta package with a flag file (which enables pipewire's alternative pulseaudio server) inside.
In Arch, pipewire-pulseaudio provides (conflicts with) pulseaudio and pulseaudio-bluetooth.

I heard that https://github.com/pali/libopenaptx is compatible with pipewire, so maybe I will start packaging it.

Absolutely.

@gombosg
Copy link
Author

gombosg commented Dec 16, 2020

Thanks for the details!
@soredake - wow, this is so recent... like it's being developed right now.
I personally think it's too early for F34 next spring, but they pushed through the change and looks like it will make it.

And we should provide some upgrade path for users...

In Arch, pipewire-pulseaudio provides (conflicts with) pulseaudio and pulseaudio-bluetooth.

In Fedora, too.

So basically:

  • aptX, LDAC - all OK
  • aptX HD, AAC - keep an eye on it

And announce to users somehow during F34 upgrade which one is supported at that point?

@gombosg
Copy link
Author

gombosg commented Dec 16, 2020

@EHfive it's great to see you contributing to pipewire! I hope you'll have a much better experience than Pali had with PA.

@EHfive
Copy link
Owner

EHfive commented Dec 16, 2020

And we should provide some upgrade path for users...

I think it's quite easy to upgrade as long as bluez5 support is enabled by default on packaging.
End users can transparently replace pulseaudio with pipewire without any configuration requirements.

@EHfive EHfive removed the bug Something isn't working label Dec 20, 2020
@IDeathByte
Copy link

i hope extended sbc profiles will be supported in pipewire too :)
i have better experience on my headphones than with aptx (no quantum-noises and higher bitrate)

Thanks for your work :)

@gombosg
Copy link
Author

gombosg commented Dec 21, 2020

Well, for Fedora we have libldac and I started packaging libopenaptx.
Looks like this pulseaudio-modules-bt will be removed during the upgrade, because pipewire replaces pulseaudio, and hence pulseaudio-modules-bluetooth as well.
For AAC support I can't say anything, maybe it won't be supported by pipewire unfortunately.

@soredake
Copy link

Only blocker for migrating to pipewire for me is this and this

@soredake
Copy link

Seems ubuntu and debian not ready for using pipewire as pulseaudio replacement :(
изображение

@soredake
Copy link

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants