pipewire: cannot eject (drop) disconnected stream

[strohel]

Bug Description

In our application we have code that detects when the audio callback isn't called, and try to recreate the stream if that happens. However, when trying to clean up the old stream, calling AudioStreamHandle::eject() on it hangs forever.

Ejecting a stream that is running normally works.

Steps To Reproduce

1. Start a stream (capture or playback, doesn't matter) using the pipewire backend
2. Trigger a condition where the audio callback is no longer called. Either:
   a. disconnect any connections from the stream node in pipewire patchbay tool like qpwgraph, helvum or pw-viz
   b. disconnect the (USB) sound card that the stream was running on (depending on pipewire/wireplumber config, it may get reconnected to a different stream though)
3. Call AudioStreamHandle::eject() on it

Expected Behavior

The stream is ejected and cleaned up immediately.

Actual Behavior

The eject() call hangs, and the stream still exists in tools like pw-top, wpctl status, pipewire patchbay tools.

Once I trigger the audio callback being called again (i.e. by manualy connecting the stream's node to some device in a patchbay tool), it finally ejects and is cleaned up.

Environment

• OS: Linux (Gentoo, Arch)
• Audio driver (enable info logs): pipewire
• Rust Version: 1.90.0
• Project Version/Commit (see Cargo.lock): 7f73ef5 (recent main as of 2025-10-28)

Additional Context

The root cause is likely around

interflow/src/backends/pipewire/stream.rs

Lines 194 to 196 in 7f73ef5

	.process(move |stream, inner| {
	log::debug!("Processing stream");
	inner.handle_commands();

We only ever process the commands inside the the audio callback. But pipewire doesn't call that one when the node is disconnected.

Pipewire allows many different types of callbacks/communication patterns on the stream and in its MainLoop, which would likely be a better way to process commands.

This is also related to #77

Aside 1

I see that interflow uses pipewire in somewhat non-canonical way: it spawns a pipewire MainLoop per every stream (which then spawns another "data loop" for the audio callback). I think the intended way is that a single MainLoop is spawned (more or less globally) and then streams are added/removed from that loop. If this something interflow wants to transition to?

Aside 2

Was the API AudioStreamHandle::eject() returning the callback back to the caller inspired by something?

I imagine getting the callback back may be handy in some cases (though not ours), though it complicates the implementation slightly: sending some one-shot "please drop and destroy yourself" to the stream would be more straightforward. (callers would be still able to get data back from the callback by wrapping it in something like Arc<Mutex<Option<...>>>, though that isn't elegant)

Aside 3

In the previous backends that we've used (portaudio, cpal), dropping the stream handle resulted in stopping and disposing of the stream. In interflow, the stream keeps running in this case, without any way to stop it afterwards (short of panicking in the callback).

Is this intentional?

Possible Solution

For our use I've implemented a hacky work-around in tonarino#5. It works for us, but I don't think it's upstreamable as-is (for example eject() takes up to a second).

If you have an idea how you want to address this architecturally I can try implementing that.

CC @mbernat @jacksongoode.

[SolarLiner]

As a preface, I'll say that I don't really know the PipeWire API and the current backend implementation is the result of "let's cobble something until it works". The lack of documentation on the Rust crate itself means I had to read the C docs, and manually translate the code snippets (also, I have had trouble understanding these docs too, something about the way it's laid out and explained makes it hard for me to understand purpose and intended usage). Therefore anything done in this backend (or any backend, really), isn't to be taken as gospel, and implementation details are up for comment.

The approach of "ejecting" comes from allowing users to get their audio processing callback back when a stream finishes, and being able to start another stream with it, maintaining state across (also useful for eventually reacting to the OS changing default I/O devices, for example). There could also be another, simpler "drop stream" option that does not activate that mechanism, and simply lets the callback destroy itself. In any case, dropping the stream should stop playback, and it does so on other platforms.

More specifically, the current approach indeed requires the callback to be called one more time after an eject is called; this is because the ownership of the Audio*Callback is moved inside this callback, and to bring it back, we have to extract it. I don't really know of any other way, but you are free to propose what you think is a correct implementation of this backend, be it as a high-level overview, or a full implementation if you wish.

The problem of using a Mutex is that this makes the callback not lock-free, which is a requirement for glitchless audio processing, therefore we can't use that. We cannot share the ownership of the audio processing callbacks as a result. Maybe there is an event-based API that allows reacting to the stream pausing, or we could have a timer that runs in parallel, that PipeWire provides with our inner data as well, so that we can safely eject the stream even when the stream is paused.

[strohel]

Alright, thanks for the info. I'll give solving this in a reasonable way a try and submit a PR if something comes out of it.

Maybe there is an event-based API that allows reacting to the stream pausing

There indeed is, I was experimenting with and we get a stream state change notification.

pipewire-rs has its own soundness problems w.r.t. the callbacks (esp. with RT_PROCESS), but it is possible to circumvent it.

[SolarLiner]

It looks like RT_PROCESS requires the callback is Send + Sync? Audio callbacks in interflow are already required to be Send, and in the case of PipeWire, communication between the stream and the main thread is already Sync (though it looks like not enforced). Therefore we should be safe, but countermeasures against this issue are welcome too.