[ISSUE] Regression involving async nodes in PipeWire 1.2.1 results in recording underruns

[KynikossDragonn <KynikossDragonn@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

New issue by KynikossDragonn on void-packages repository

https://github.com/void-linux/void-packages/issues/51474

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.41_1 x86_64 GenuineIntel notuptodate hold rrmDFFFFFFFFFFFFFF

### Package(s) Affected

pipewire-1.2.1_1

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4138
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/db710359ad42c7c658b3168c50c9c7a3d863bba5

### Expected behaviour

Device Monitor recordings should not underrun when a native PipeWire client is outputting to the device in question.

### Actual behaviour

Device Monitor recordings will start underrunning if any native PipeWire client is presently outputting audio to said device.

The underrunning is not reported to the terminal or `pw-top` as errors, even if you run things with `PIPEWIRE_DEBUG=3` as a environment variable.

This can be worked around by avoiding the use of the native PipeWire client protocol and instead use the ALSA compatibility layer. (i.e.: `SDL_AUDIODRIVER=alsa` for SDL2 executables or setting in `drivers = alsa` in `.alsoftrc`)

According to the response from upstream this is something to do with PipeWire's recent introduction to the concept of "asynchronous processing" though I don't recall having this issue with PipeWire 1.2.0 _(which introduced this)_ or PipeWire 1.1.83.

### Steps to reproduce

1. Play audio "natively" through PipeWire (it can be by pw-cat, a SDL2 executable, a Open AL Soft executable, Mumble, anything that uses PipeWire directly)
2. Try to record audio via the monitor. (pw-record, OBS with the native PipeWire audio plugin, anything that uses PipeWire directly)