Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pipewire permission issue after 1.0 release #398

Open
shetozz opened this issue Feb 28, 2024 · 10 comments
Open

pipewire permission issue after 1.0 release #398

shetozz opened this issue Feb 28, 2024 · 10 comments

Comments

@shetozz
Copy link

shetozz commented Feb 28, 2024

In the flatpak permissions, pipewire is set to xdg-run/pipewire-0:ro this leads to audio not working if the system's pipewire version is 1.0.x, changing the permission to xdg-run/pipewire-1:ro solves the issue.

@Erick555
Copy link
Contributor

Erick555 commented Feb 28, 2024

this leads to audio not working if the system's pipewire version is 1.0.x

what do you mean? socket number isn't related to pipewire version. I have pipewire 1.0.3 and socket is still named pipewire-0. Maybe if you have multiple pipewire servers running at same time then you would have different socket number but I don't think this is workable.

@shetozz
Copy link
Author

shetozz commented Feb 28, 2024

Not sure what's going on, as I have no experience in any of this stuff, but that's what happened to me.

@Erick555
Copy link
Contributor

do you still have pipewire-1 socket after reboot?

@shetozz
Copy link
Author

shetozz commented Feb 29, 2024

Yeah, still -1 even after restarting.

@Erick555
Copy link
Contributor

Is there only -1 or both -1 and -0? This is very strange situation which would break all flatpaks that use pipewire. You may ask in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues about it.

@shetozz
Copy link
Author

shetozz commented Feb 29, 2024

I just found out something even weirder, it's not just -1 that works, any number other than -0 works, and even removing the permission altogether works, but resetting it to default breaks audio, -plays mp3 files, but audio in video files doesn't work-

@Erick555
Copy link
Contributor

Erick555 commented Feb 29, 2024

Can you show ls /run/user/<user id number> output?

I guess pipewire audio output is simply broken on your system and audio works only when you block actual pipewire socket and use some fallback.

@shetozz
Copy link
Author

shetozz commented Feb 29, 2024

 .dbus-proxy         app        gnome-shell     gvfsd       .mutter-Xwaylandauth.5TFDJ2        ICEauthority                pipewire-0.lock
 .flatpak            at-spi     gnupg           keyring     Alacritty-wayland-0-49215.sock     pipewire-0                  wayland-0
 .flatpak-cache      dconf      gsconnect       pulse       bus                                pipewire-0-manager          wayland-0.lock
 .flatpak-helper     doc        gvfs            systemd     gnome-session-leader-fifo          pipewire-0-manager.lock

@Erick555
Copy link
Contributor

Erick555 commented Feb 29, 2024

yeah, your socket name is pipewire-0 which is right. By changing permission from pipewire-0to pipewire-1 you actually blocked pipewire access which accidentally helped because the problem is pipewire didn't work at all with flatpak (and pulseaudio fallback worked). There were similar issues about pipewire in the past.

@shetozz
Copy link
Author

shetozz commented Feb 29, 2024

Okay, gotcha.
I followed the trace instructions in the other issue and it's just a spam of this line

[ao/pipewire] queued 2048 of 2048 samples
[ao/pipewire] queued 2048 of 2048 samples
[ao/pipewire] queued 2048 of 2048 samples
[ao/pipewire] queued 2048 of 2048 samples
[ao/pipewire] queued 2048 of 2048 samples
[ao/pipewire] queued 2048 of 2048 samples

with the occasional

[vo/gpu/wayland] Received a new DND offer. Releasing the previous offer.
[cplayer] Set property: user-data/osc/margins={"l":0,"t":0,"b":0,"r":0} -> 1

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

Successfully merging a pull request may close this issue.

2 participants