PipeWire: fix stopped stream ejection

[strohel]

Description

Fixes #105, at least for me.

To be reviewed by commits:

• first commit adds a new example eject_stream_pipewire.rs, which hangs at this point
  • this would be even better as an integration test, but it requires running pipewire, output device, the pw-link command
• the second commit is a small cleanup/refactor to make the following change easier
• the third commit is the actual bugfix
  • instead of handling StreamCommands in the process() callback (which runs in the RT thread), we now handle them in the PipeWire main loop. This also prompted a transition from rtrb to pipewire::channel; this makes their handling independent
  • a Mutex is introduced in the audio callback but we never wait on it in the audio process() callback. I tried hard to avoid it, but I believe it is necessary (short of unsafe code), as we need &mut access to the Option<Callback> in two separate threads.

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Code cleanup or refactor

How Has This Been Tested?

• Tested by introducing the eject_stream_pipewire.rs example.
• Test in more realistic setting that is works at least as good as Don't merge: process stream commands also when stream is paused (hotfix stream ejection) tonarino/interflow#5 @mbernat maybe? 🙏

Checklist:

• My code follows the style guidelines of this project
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Wherever possible, I have added tests that prove my fix is effective or that my feature works. For changes that need to be validated manually (i.e. a new audio driver), use examples that can be run to easily validate them.
• New and existing unit tests pass locally with my changes
• I have checked my code and corrected any misspellings

CC @mbernat. Supersedes tonarino#5.

[strohel]

I just learned about this pipewire property:

• node.always-process = false
  When the node is active, it will always be joined with a driver node, even when nothing is linked to the node. Setting this property to true also implies node.want-driver = true.
  This is the default for JACK nodes, that always need their process callback called.

So in theory setting this property could fix the issue without the complexity of this PR (but with some side-effects). I'll give it a try.

[mbernat]

@strohel Were you able to try node.always-process in the end?

[strohel]

@strohel Were you able to try node.always-process in the end?

I haven't tried yet, will do once I find time. I think it will also break our "callback not called" detection, but that's not something the upstream should be concerned about.

[SolarLiner]

@strohel please rebase onto, or merge main, to update your branch, and I'll merge after CI passes 👍🏻

[strohel]

Rebased, the eject_stream_pipewire.rs example still executes correctly as a sanity check.