Talk:PipeWire

0.3.16 pulse replacement

For the pulse-dropin-replacement to work, you probably also need to clear your users config, ~/.config/pulse (like in delete/move the content) - That is created by pulseaudio for pulseaudio. Otherwise the server could be unable to start.

Fabis.cafe (talk) 14:12, 23 November 2020 (UTC)

---

I just installed the pulse replacement and while everything seems to be working just fine, the only problem is gnome-shell doesn't seem to be able to see the pipewrire pulse server, thus the volume control in the top right system menu is absent and keyboard media keys for volume don't work either. I think this should be addressed in the troubleshooting section with a solution if there is one.

Interestingly enough gnome-control-center is able to control the volume as well as other typical pulseaudio parameters.

UPDATE: running killall pipewire-pulse; killall pipewire restarts the pipewire pulse daemon and makes the volume control in gnome-shell work as expected. This of course is a workaround and not a proper solution.

UPDATE 2: the above makes the volume control menu item and shortcuts appear, but adjusting the volume does nothing.

GabMus (talk) 09:39, 3 December 2020 (UTC)

I don't see volume indicator in gnome-shell/wayland but I'm able to control volume with media keys. -- Svito (talk) 15:55, 3 December 2020 (UTC)

Possibly related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/426 Hexchain (talk) 18:05, 3 December 2020 (UTC)

Solved, refer to the latest change I made in the main page, found the solution thanks to Hexchain's link. -- GabMus (talk) 19:55, 4 December 2020 (UTC)

aptX support

Does `pipewire` support low latency/high quality bluetooth codecs (aptX, LDAC, ...) ? along the lines of https://aur.archlinux.org/packages/pulseaudio-modules-bt-git/ If yes, how to configure it? along the lines of https://freedesktop.org/software/pulseaudio/pavucontrol/ nTia89 (talk) 21:23, 3 December 2020 (UTC)

I switched to PipeWire and currently bluetooth sound poorly works: high latency and low quality.

Actually open bug/enhancement in pipewire bugtracker [1].

nTia89 (talk) 10:20, 5 December 2020 (UTC)

It does now but currently there is no way to select a codec manually. It uses (the first supported?) codec in this order: LDAC, AptX HD, AptX, SBC. You can check for the current codec with pactl list sinks IIRC.

Hexchain (talk) 00:41, 21 December 2020 (UTC)

In the meantime, pipewire gets updated with support of the above mentioned feature; at the same time GNOME's sound setting allows to select (supported) codec

nTia89 (talk) 06:31, 1 May 2021 (UTC)

Better introduction?

Right now I think the description is missing some content to exactly explain what pipewire is and what it can be used for. The website names some important examples imho:

• Capture and playback of audio and video with minimal latency.
• Real-time Multimedia processing on audio and video.
• Multiprocess architecture to let applications share multimedia content.
• Seamless support for PulseAudio, JACK, ALSA and GStreamer applications.

G3ro (talk) 15:21, 28 February 2021 (UTC)

I fully agree! TBH I don't see an urgent need for a discussion on this topic. Feel free to amend the page with whatever you think is right. -- Edh (talk) 19:30, 3 March 2021 (UTC)

Ok, I have added some parts. Someone with better knowledge on this topic might edit it further.

G3ro (talk) 20:26, 5 March 2021 (UTC)

Move section "webrtc screen sharing" below other sections in "Usage"

I think that the "Audio" and "Video" sections are more important and more general, so they should be placed first.

G3ro (talk) 15:23, 28 February 2021 (UTC)

IMHO the ordering is just fine as of now. Pipewire is completely optional for handling audio and video. However, for screensharing under wayland you must use it. I strongly believe that this section is of most interest to the average user. Note, I am fine though with whatever reaches a consensus. I do not feel too strongly about the ordering of these sections. -- Edh (talk) 19:28, 3 March 2021 (UTC)

For now I would be ok with the ordering, but afaik Pipewire is aimed to become some kind of "replacement" for pulseaudio etc., so the other parts will become more important in the future.

G3ro (talk) 20:33, 5 March 2021 (UTC)

0.3.23 no pcm devices found

Thanks nTia89 for reverting my change. pipewire-alsa isn't needed, I checked contents of the package, it definitely can't help.

Spent 5h on pipewire, it did not find any sound-card. The moment I installed pipewire-alsa it started working. I used pw-cli ls | grep -i pcm to find pcm devices. I didn't change any config the whole time, because the wiki-page says it should work out of the box. I rebooted a lot. I hoped I could help that other users don't have to spend 5h on this. pipewire seems very nice. So here is what I did in the end.

• install pipewire pipewire-media-session pipewire-alsa pipewire-jack pipewire-pulse pipewire-jack-dropin (ignore jack if you don't have jack-applications)
• remove pulseaudio
• systemctl --user enable pipewire.socket pipewire-pulse.service pipewire-media-session.service
• systemctl --user restart pipewire.service pipewire-pulse.service pipewire-media-session.service

I try to find out what exactly my mistake was.

Streampunk (talk) 14:59, 22 March 2021 (UTC)

Native pulse clients can't connect

pipewire-pulse-dropin (AUR) has existed until Nov 2020. If still installed, it shadows and conflicts the socket /run/user/*/pulse/native which is now already provided by pipewire-pulse.service. Delete that orphaned package to solve this issue. Sausix (talk) 15:10, 30 March 2021 (UTC)

Configuration section

I think we have to mention the official wiki page: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Configuration#set-global-sample-rate because it is a complete and always up-to-date resource.

I think we should add a Configuration section; a sort of:

`PipeWire is a powerful tool having a plethora of options. We recommend to read the official wiki page[1] in order to have a complete sight of all possibilities. Although most users are happy with default settings, particular configuration cases are reported in the Pipewire/Examples page. On the other hand, most common issues and their solutions are reported below in the Troubleshooting section.`

What do you think?

nTia89 (talk) 10:16, 27 March 2021 (UTC)

I fully agree with you about mentioning the official wiki page. However, I think it is fine to recap some of the most important configuration options in the ArchWiki too! At least to me the current phrasing of the paragraph suggests that we solely refer to the official wiki page for that. -- Edh (talk) 11:03, 27 March 2021 (UTC)

Maybe add info about Pipewire wiki in a new Configuration section and below that add " Configurations for some of the most common usecases are provided in the following [usage] sections. " RaZorr (talk) 07:54, 8 December 2021 (UTC) .

video production ready?

The video section currently claims that:

> Although the software [video in PipeWire] is not yet production-ready, it is safe to play around with.

(emphasis mine). What's the source for the claim? The PipeWire (PW) FAQ basically says "It [PW] is ready for broader use", so I wonder where that dissonance comes from. --Anarcat (talk) 18:45, 6 May 2021 (UTC)

Elaborate on the expectations/requirements of the jack/jack2 removal option

The page currently suggests removing jack/jack2 from your system as an alternative to running through `pw-jack` or installing pipewire-jack-dropin^AUR to have the system use PipeWire for JACK but this is most likely blocked by a lot of software unless you've installed said software on your system without involving `pacman` and thus not having the transaction blocked, or you would need to force the removal (and IgnorePkg it to prevent it from returning) or maybe NoExtract jack's *.so files? The way it is suggested makes it sound like it should be a very easy `pacman -Rns jack/jack2` which it more than likely will not be.

Examples of programs that would block a simple/normal removal as suggested are blender and ffmpeg looking for 'jack', or things like qemu and fluidsynth looking for 'libjack.so=0-64'.

Maybe this section should have a note about that or maybe it's better to remove that whole suggestion as an option?

—This unsigned comment is by Omar007 (talk) 15:36, 10 June 2021. Please sign your posts with ~~~~!

Screensharing not functional with wireplumber?

It looks to me that wireplumber, while mentioned as more powerful in the wiki page, does not allow screen sharing at least with sway. Replacing it with pipewire-media-session fixes the issue. xdg-desktop-portal[-wlr] and wireplumber bugtrackers and docs do not mention anything about it.

Does anyone have a different experience or should we mention it in the wiki?

EDIT: it looks like it's fixed as of xdg-desktop-portal-wlr v0.5.0

--Njoyard (talk) 20:56, 26 October 2021 (UTC)

Unclear that we need pipewire-media-session or wireplumber

It is heavily implied that just installing and enabling Pipewire is enough to make it work. Everyone talks about how Pipewire is a drop-in replacement, the section on replacing pulseaudio doesn't mention it, and the Wireplumber subheading has the same style and appears after GUI, implying that it is optional just like the GUI frontend. However, this is not the case. Pipewire does not recognize any audio devices unless I start pipewire-media-session.service or install and start wireplumber. I feel like it should be explained in whatever the relevant section is that you must do one of these things.

0100001001000010 (talk) 03:25, 28 December 2021 (UTC)

We do need a session manager as detailed on PipeWire's documentation:

A correctly installed PipeWire system should have a pipewire process, a pipewire-media-session (or alternative) and an (optional) pipewire-pulse process running.

Therefore users must install either pipewire-media-session or wireplumber. Both still work. I am editing the page to clarify this.

--Dllud (talk) 14:46, 30 January 2022 (UTC)

I just want to mention that currently PipeWire#Session_manager says "When installing PipeWire you will be asked to opt between one of them", however I just installed pipewire and did not get asked. So it should probably be mentioned in this subsection, preferrably before the listing of session managers, that one should install one. Or the pipewire package should be fixed so that one actually gets asked to install a session manager (probably more convenient for the useres). Mearon (talk) 10:20, 26 April 2022 (UTC)

Adding some clarification to the discussion: pipewire has an optional dependency on the pipewire-session-manager virtual package (either wireplumber or pipewire-media-session). Meanwhile, the audio server packages (pipewire-alsa, pipewire-pulse and pipewire-jack) have hard dependencies on pipewire-session-manager. If PipeWire really requires a session manager to work even when you are not using it as a replacement for other audio servers, then this a packaging bug that needs to be fixed.

--Aurantius (talk) 14:37, 2 May 2023 (UTC)

Well, screen sharing on Wayland does not work without pipewire-media-session, so yeah, this should probably be a hard dependency. Cbrnr (talk) 05:07, 3 May 2023 (UTC)

As far as I remember, it works with wireplumber instead of pipewire-media-session as well. — Lahwaacz (talk) 08:03, 7 May 2023 (UTC)

Yes, but as the title of this discussion says, either pipewire-media-session or wireplumber is *required* for screen sharing, so this package group should be a hard dependency instead of only recommended. Cbrnr (talk) 08:49, 7 May 2023 (UTC)

xdg-desktop-portal-wlr depends on the pipewire-session-manager virtual package so the dependencies are handled correctly on the package level. You are free to submit a bug report for the XDG Desktop Portal backend you are using. — Lahwaacz (talk) 09:09, 7 May 2023 (UTC)

Would it be possible to mention the pipewire-media-session requirement also in the PipeWire#WebRTC_screen_sharing section? This would have saved me a ton of time. Cbrnr (talk) 13:12, 2 May 2023 (UTC)

pipewire.conf is NOT in /etc/pipewire

after a fresh install of archlinux and pipewire and pipewire-pulse:

1. find / -mount -name pipewire.conf

/usr/share/pipewire/pipewire.conf

I assume the documentation should be edited to reflect this, (it currently states that the path is /etc/pipewire/pipewire.conf)

by default the directory /etc/pipewire does not exist.

the header of /usr/share/pipewire/pipewire.conf states that one should copy the file to /etc/pipewire (or ~/.config/pipewire)

I think the documentation should reflect this:

if file does not exist copy template from /usr/share/pipewire/pipewire.conf then edit.

I dare not do the edit myself as this is my first ever contribution FatherFunky (talk) 04:55, 10 January 2022 (UTC)

Welcome to ArchWiki! To get a definitive idea of what configuration paths a software uses, its manpages are a good place to start. According to pipewire.conf(5) § SYNOPSIS, Pipewire will read from both of those two paths. file-hierarchy(7) explains that /etc/ is used for system specific configuration, whereas /usr/ is for vendor supplied resources. Indeed, in the Pipewire file list you can see that it ships the file in /usr/. As a result, changes you make to the that config file will be backed up and overwritten by a package update. I am editing the documentation to clarify this. - CodingKoopa (talk) 23:19, 10 January 2022 (UTC)

pipewire-jack-dropin/ deleted and now "pipewire-jack and jack2 are in conflict (jack). Remove jack2?" but too many dependencies

https://aur.archlinux.org/packages/pipewire-jack-dropin/ was deleted and now "pipewire-jack and jack2 are in conflict (jack). Remove jack2?" but there are too many dependencies on jack2 to remove it.

The wiki should provide some legacy advice for those affected by this because the comments section of https://aur.archlinux.org/packages/pipewire-jack-dropin/ is gone now.

See https://web.archive.org/web/20211204135226/https://aur.archlinux.org/packages/pipewire-jack-dropin.

—This unsigned comment is by Elijah Lynn (talk) 01:02, 26 January 2022. Please sign your posts with ~~~~!

There is a comparison table explaining the differences between the JACK implementations. Before removal of the pipewire-jack-dropin PKGBUILD I have left a comment, which instructs the user to uninstall the package because it is no longer required. FWIW, if there are any dependents on jack2, then it is likely jack2-dbus, which itself only has cadence as single dependent. Can you elaborate on why it would be important to explain package dependency resolution to the user in this particular case, but not in another? After all, it highly depends on what the user installed. -- Davezerave (talk) 13:58, 26 January 2022 (UTC)

Move Troubleshooting into a new separate page

In order to display section headings better like Pipewire#Fix pipewire-media-session the troubleshooting sections should be moved into a new wiki page. This would follow the layout of the PulseAudio/Troubleshooting as well and make the site better readable. —This unsigned comment is by LukasF (talk) 2022-08-15T12:22:44. Please sign your posts with ~~~~!

We should think twice (or even more) before splitting a page to avoid needless back-and-forth content moves. There are significantly longer subpages marked to be merged back to the main page, e.g. Firefox/Tweaks. — Lahwaacz (talk) 06:07, 16 August 2022 (UTC)

Okay this makes sense. According to Help:Effective use of headers#Multi-level structure one should use section headings for more in depth articles. But my problem is that section headings level 5 and 6 look like level 4 Sandbox#Header_level_1. I would like a standard way to see the hierarchy of headings while reading, making longer in depth articles more readable. Is there a simple way I overlooked or should I start a discussion on Help:Effective use of headers? Should I use a section heading for PipeWire#With_pipewire-media-session? -- LukasF (talk) 12:25, 16 August 2022 (UTC)

Once upon a time, MediaWiki had an user setting to auto-number the sections, but they removed it in a recent version. It's possible to hack it with a user CSS, we should probably merge it into the global stylesheet and figure out how to make it configurable (or just leave it on for everybody...) — Lahwaacz (talk) 20:27, 16 August 2022 (UTC)

To avoid the performance issues, we could instead use a different text color for each header level. -- nl6720 (talk) 13:58, 17 August 2022 (UTC)

The performance issues are related to the original server-side solution, not to the CSS workaround. — Lahwaacz (talk) 11:53, 10 September 2022 (UTC)

Created a new discussion in Help talk:Effective use of headers#How can we make deep articles with Multi-level structure more readable? for this topic. -- LukasF (talk) 17:06, 19 August 2022 (UTC)

I just moved the CSS workaround to MediaWiki:Common.css, so the sections should be auto-numbered for everybody now. — Lahwaacz (talk) 11:53, 10 September 2022 (UTC)

[Section 3.1.5: PipeWire patch sets for command line] 0.3.57 removes pw-cli dump

From what I can tell, the snippets in PipeWire#PipeWire_patch_sets_for_command_line were taken from this issue by Jonathan Brickman.

Since release 0.3.57, these no longer work, as it removes the pw-cli dump command. Since the output of pw-dump is not the same syntax, I don't think it's trivial to rewrite the scripts.

For saving and loading wires, I wrote the following alternatives for personal use:

pw-savewires

#!/usr/bin/env node

const output = process.argv[2]
if (!output) throw 'no filename specified'

const { execSync } = require('child_process')
const { writeFileSync } = require('fs')

const input = execSync('pw-link --links').toString()
const reg = /^(?<source>[\w\:\.\-]+)(?<actions>(?:\n\s+(?<action>\|\-\>|\|\<\-)\s+(?<target>[\w\:\.\-]+))+)/mg

const matches = []
let match;
while ((match = reg.exec(input)) !== null) matches.push(match.groups)

const links = matches.flatMap(match => {
	const link = []
	const { source, actions } = match
	const targetStrings = actions.split('\n').slice(1).map(s => s.trim())

	for (const targetString of targetStrings) {
		const [direction, target] = targetString.split(/\s+/)
		link.push([source, direction.replace('|', ''), target])
	}

	return link
})

const json = JSON.stringify(links, null, 2)
writeFileSync(output, json)

pw-loadwires

#!/usr/bin/env node

const input = process.argv[2]
if (!input) throw 'no filename specified'

const { exec } = require('child_process')

const json = require(input)

for (const link of json) {
	const [source, direction, target] = link

	switch(direction) {
	case '->':
		exec(`pw-link ${source} ${target}`)
		break
	case '<-':
		exec(`pw-link ${target} ${source}`)
		break
	default:
		throw `invalid direction: ${direction}`
	}
}

I was wondering whether these are welcome as changes to the article? If so, feel free to go ahead, CC0.

MyMindIsHazel (talk) 19:02, 14 November 2022 (UTC)

Node.js would be an interesting choice for the wiki article, as there's not the greatest guarantee of the reader having it installed. Though I would prefer for it to be Python, it is more functional than what we currently have. Seems fine to add. -- CodingKoopa (talk) 22:47, 15 November 2022 (UTC)

Disable unwanted outputs, inputs, AUXes, and other objects

I have been looking for a way to disable (hide) the unwanted outputs, inputs, auxes, and other objects such as HDMI1-3 in PulseAudio and JACK on my laptop that I use. After a great deal of time and effort, I finally found a way that works (at least in my environment). I had a very hard time finding this setting, but it seems a bit hacky. Could someone please review it to see if I'm doing something wrong (and if so, I'd appreciate it if you could give me an alternative solution as well). I will wait a week or so for the mistakes to be pointed out, and if it looks OK, I will publish it.

—This unsigned comment is by Tkna (talk) 08:59, 6 February 2023. Please sign your posts with ~~~~!

It seems hacky that we are invoking pw-cli from a config file, but I imagine that it does work. I made some edits; this can probably be added to a Tips and Tricks top-level section above Troubleshooting. It's a bit too niche for the general Configuration section, I think. Thanks, CodingKoopa (talk) 17:49, 23 February 2023 (UTC)

Disable unwanted devices

You can use pw-cli(1) § destroy to disable unwanted outputs, inputs, and AUXes. You can integrate this into your configuration like so.

/etc/pipewire/pipewire-pulse.conf.d/10-destroy.conf (or ~/.config/pipewire/pipewire-pulse.conf.d/10-destroy.conf)

context.exec = [

    # output
    { path = "pw-cli" args = "destroy alsa_output.pci-0000_00_1f.3-platform-sof_rt5682.pro-output-0" }
    { path = "pw-cli" args = "destroy alsa_output.pci-0000_00_1f.3-platform-sof_rt5682.pro-output-2" }
    { path = "pw-cli" args = "destroy alsa_output.pci-0000_00_1f.3-platform-sof_rt5682.pro-output-3" }
    { path = "pw-cli" args = "destroy alsa_output.pci-0000_00_1f.3-platform-sof_rt5682.pro-output-4" }

    # input
    { path = "pw-cli" args = "destroy alsa_input.pci-0000_00_1f.3-platform-sof_rt5682.pro-input-0" }
    { path = "pw-cli" args = "destroy alsa_input.pci-0000_00_1f.3-platform-sof_rt5682.pro-input-8" }

    # aux
    { path = "pw-cli" args = "destroy alsa:pcm:0:hw:0,1:capture:capture_2" }
    { path = "pw-cli" args = "destroy alsa:pcm:0:hw:0,1:capture:capture_3" }

]

Use pw-cli ls to get the identifiers of the devices.

Why is there no mention of enabling the services through systemd?

It mentions using systemd drop-ins for activation, but there is no mention of enabling the services required to run. The information is fragmented and hazy. I had to follow the steps from this github repo to get it working correctly. I suggest incorporating that info here. I do not know if it is actually good information, and that is why I'm suggesting it, so people with the appropriate know-how can verify the info. --ParaPsychic (talk) 07:23, 12 March 2023 (UTC)

The sockets are enabled by default after installation of the packages, see e.g. [2]. — Lahwaacz (talk) 09:03, 12 March 2023 (UTC)

Sorry, I missed that. Is wireplumber service also enabled by default? I had issues with my microphone not picking up any noise at all, and enabling all three somehow fixed my issues. Or maybe it's because of some conflicts with existing pulseaudio programs. Anyhow, thank you. ParaPsychic (talk) 15:39, 12 March 2023 (UTC)

Yes. — Lahwaacz (talk) 15:46, 12 March 2023 (UTC)

Pipewire.service now lives at user space, how should we change the wiki page to prevent misleading

Hi, this is my first time to contribute to ArchWiki, so I might ask some basic questions.

I came across that you can't enable pipewire.service globally, it lives now at user space. I think the wiki page contains information that is outdated.

So How should we change it?

Lumen Yang (talk) 22:15, 8 April 2023 (UTC) Jiaye Yang

What are you referring to exactly? You don't need to enable pipewire.service, and there are no advices about doing that on the page, because it is activated automatically.

Also it never was global iirc and literally described as a user unit everywhere across the page.

Hanabishi (talk) 22:35, 8 April 2023 (UTC)

pipewire group, recommendations around not using audio/rtkit/realtime groups

After struggling to get pipewire setup properly today (May 2023), I would like to propose updating the recommendations around rtkit/realtime, and the advice around RLIMITs.

There seems to have been some changes to the way PipeWire handles realtime, and the current recommendations for users. The current recommendation (from what I can tell, as of May 2023) is for the user to create a pipewire group and add themselves to it, so that PipeWire can use the native libpipewire-module-rt module, instead of rtkit.

The user will also need to add the recommended configuration to a file in /etc/security/limits.d/, (95-pipewire.conf is the recommended name, can be whatever).

Adding themselves to the pipewire group means then they won't have errors such as org.freedesktop.DBus.Error.AccessDenied. [As of version 0.3.66 PipeWire generates /etc/security/limits.d/25-pw-rlimits.conf].

I also think that the recommendation around adding the user to the realtime group should be changed, as it's better to have a group dedicated to pipewire incase there are other realtime group usages.

It might also be worth stating the user shouldn't be in rtkit or audio if using PipeWire.

Audio group issues.

I'd be happy to write this if people are happy.

Joshtau (talk) 17:27, 11 May 2023 (UTC)

Looks good to me ! Just tested your recommendations sum-up, and got rid of the real-time warnings from `systemctl --user status pipewire`. la Fleur (talk) 11:43, 4 April 2024 (UTC)

Wireplumber Automatic profile selection config outdated

See ArchWiki talk:Requests#Update for new WirePlumber configuration format.

I don't understand the new config format myself but an updated version of this one would be great. Silikeite (talk) 09:46, 22 March 2024 (UTC)

I'm just going to use this heading, since it's all related, but most of the old wireplumber configs are broken. I've added the "out-of-date" tag to the top of the article, with a link to a useful page. @Silikeite have a look and see if that link helps, otherwise I might be able to help work it out. For the wiki page, I've modified part of "5.1.13 Noticeable audio delay or audible pop/crack when starting playback", but there's still a lot of other sections that need to be fixed, and I am in no position to confirm if they work. Ostiensis (talk) 06:51, 26 March 2024 (UTC)

ATM the only way to change a card's profile manually is by using `pavucontrol` or `pactl`. Meanwhile I wrote the following snippets to do that from cmdline :

- List all audio devices that pipewire is aware of.

list_devices() {

   pw-dump | jq -r '.[] | select(.type == "PipeWire:Interface:Device") | [.id, .info.props."device.description"] | @tsv'

}

- List all available profiles for an audio device. argument #1 (device id) is as found in `list_devices` or `wpctl status`

list_profiles() {

   pw-dump | jq -r ".[] | select(.id == $1) | \

      .info.params.EnumProfile | \

       .[] | [.index, .name] | @tsv"

}

- Modify the currently used profile for an audio device.

set_profile() {  # $1: device id, $2: profile id

  wpctl set-profile $1 $2

}

la Fleur (talk) 11:50, 4 April 2024 (UTC)

Remove wireplumber config for < 0.5?

Should we add the new wireplumber configuration (>= 0.5) or replace the existing (LUA) wireplumber configuration? Rudis (talk) 09:02, 15 May 2024 (UTC)

Oh, and maybe remove PipeWire Media Session configuration while we're at it? Rudis (talk) 09:13, 15 May 2024 (UTC)

Yes, I mentioned that in the comment thread above this, and I previously added the `Out of date` template to the main article. It's just a massive change that will require a lot of work that I don't have time for right now. I'm totally happy for anyone else to take it on board though! Ostiensis (talk) 09:23, 15 May 2024 (UTC)

Mostly done. There are still two .lua configs and a few PipeWire Media Session only configs left. Not sure how to test the replacements so I will leave them for now. Rudis (talk) 08:50, 30 May 2024 (UTC)

That's great. Thanks for doing that @Rudis! Ostiensis (talk) 09:03, 30 May 2024 (UTC)