I ran into this bug with 1.4.2-1 after upgrading to trixie. I believe that including https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2544 (commit cfde4c1b17468d82c34555814dc19998d00d7bd1) will fix it. It looks like it cherry-picks cleanly, although I did not try building yet.
I think https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/4901 is the correct upstream bug, because it's the only upstream bug I found which mentions an indefinite increase in FDs. I found that the bug triggered consistently when leaving pavucontrol open while using Chrome and Firefox, and closing pavucontrol immediately freed most of the FDs opened by pipewire-pulse. I also found that increasing the RLIMIT_NOFILE soft limit for pipewire-pulse extended the time until running out of FDs, although the number of FDs kept increasing seemingly indefinitely (I got up to 2445 at one point). Another interesting observation for identifying this bug is that the timestamps of most of the excessive FDs in `/proc/$(pidof pipewire-pulse)/fd` show they are opened in big batches which correspond to me switching between desktops which have web browser(s) and a pavucontrol window open. The symptoms with current Firefox and Chrome (installed from upstream apt sources) are that video/audio streams freeze for some time (up to a minute or so) before starting or unpausing, and then some of them work normally while others render very slowly (a handful of frames per second). Looping video streams play the same way (normally or at a few frames per second) when they loop, with no delay. Sometimes the entire tab freezes while the video/audio is frozen, other times it's just the video/audio and the rest of the tab works, with no apparent pattern. Some Debian bugs that might be duplicates, although it's hard to tell from the provided information: #1056383 #1012563
