Pipewire broke for no reason today

i have been using pipewires rtp tranport for my audi for quite some time.
today, for some reason, every time i load module-rtp-send it seems to just DOS my entire lan. i have changed nothing since this was last working perfectly.

these two lines are how ive always sent audio form my steam deck to my laptop

pactl load-module module-null-sink sink_name=rtp
pactl load-module module-rtp-send source=rtp.monitor

any ideas what could be suddenly causing this?
this is on my Steam Deck

1 Like

have you tried qjackctl to map out your sink? I had issues getting pipewire terminal commands to stick on the latest linux kernel

1 Like

i have not. not sure how i would go about that on SteamOS

opting into SteamOS Beta made it work again, but its just incredibly latent now. like, several seconds. even though its supposed to be running in realtime mode

1 Like

I would add the ubuntu backports PPA and then apt install qjackctl

installing Ubuntu repos on SteamOS sounds like a terrible idea. idk how i would even get the apt and pacman systems to coexist

i tried to hit steam deck’s A/B switch to revert the update, but that just bricks pipewire entirely. so reverting isnt an option

SteamOS is based on Ubuntu. APT is standard for ubuntu based distros, it uses it for updates

SteamOS is based on arch. hence why pacman is the package manager.

Says otherwise here

well, valves website is wrong. they outa fire whoever posted that. SteamOS is arch. not debian. certainly not Debian 8, which doesnt even support Steam Deck’s CPU.

:joy: what a mess

for the record, my Steam Deck is running SteamOS 3.6.9
my laptop is Debian 12.

1 Like

You could also mod steamOS to allow snap packages or flatpaks, making it a lot easier to install something like qjackctl.

Sorry if it’s not much help, but I’ll keep bumping for you

1 Like

ill have to look into valve’s godawful documentation, but i do believe there’s a way to get flatpaks working.

not seeing anything suspicious in qjackctl.
just ruled out my laptop being at fault. i just tried the rtp stream from another machine and it works fine.
this is clearly now a SteamOS issue.

currently trying to see if pipewire has a bluetooth transport to get my deck audio into my laptop

1 Like

Looks like you’re using pulseaudio/pipewire-pulse for the rtp part via pactl. Have you tried adding a config to enable/manage rtp directly in pipewire instead? You’d throw the file in your home dir (~/.config/pipewire/pipewire.conf)

Pipewire docs: https://docs.pipewire.org/page_module_rtp_sink.html

Possible helpful reddit thread? → https://old.reddit.com/r/pipewire/comments/18f91ck/i_need_help_with_rtp_sink_and_source_configuration/

I’ve never played with RTP, so sadly I don’t have any real experience there…

1 Like

The new SteamOS 3 is Arch based (although very loosely)

This is for SteamOS 2 which is still technically the latest one available for public use, as SteamOS 3 has not yet been released for public install. There is only a restoration image for the Steamdeck.
In that sense, that website is still technically correct (which is the best kind of correct)

They are available by default and even Flathub is enabled by default.

2 Likes

ive tried doing that, but without distro-specific documentation, it seems the generic piepwire way of using ~/.config/pipewire/ bricked the audio on both debian and SteamOS

anyways, i managed to get wireplumbers bluetooth reciever going on my laptop. after forcing the sbc codec, because aptx was too latent, i can sorta game. still stuttery a bit, because bluetooth is not as good as ethernet cable.

1 Like

I have not done this myself, but you can also roll back a SteamOS update (which is the whole point why it was done as an atomic distro).

That way you can first verify if this was even an issue with the update to begin with.

1 Like