Surface stream's device being destroyed to the user

[mbernat]

Problem Statement

Streams need to be linked to devices before they can be used. There is a set of rules that determines what happens when a device is not found or destroyed called linking policy.

By default pipewire silently switches to some compatible or a default device, which is likely undesirable in most cases. It would be better to surface the problem to the user and let them decide whether they want to wait, reconfigure, or terminate the stream.

Proposed Solution

Use the following linking policy for non-default devices.

• node.dont-reconnect: true (default false) <- we get an error when the device is destroyed.
• node.dont-fallback: true (default false) <- we get an error when the device is not found; this should only happen if the device is destroyed right after enumeration, so it's much less important.
• node.dont-move: false (default false)
• node.linger: false (default false)

These errors need to be surfaced to the user in some way. The obvious choice would be to accept a new error callback, invoked in these situations; cpal also has an API of this form.

Alternative Solutions

Expose the linking policy configuration to the user. This would need to be made pipewire-specific or we would need to find a portable way to do it (presumably other drivers also have similar settings).

It might be desirable to let users specify a general Properties value so that they can tune any stream properties themselves but that's a bigger can of worms.

Example Usage

TBD

Provide an example of how this feature would be used:

// Your example code here

Additional Context

N/A

Checklist

• I have searched for existing issues that may be similar
• I have explained the feature's value proposition
• I have provided concrete examples

[mbernat]

I missed that the linking policy is a wireplumber concept and the properties are not present in the pipewire library.

Luckily, the most important piece (for my use case, at least) can be found in StreamFlags::DONT_RECONNECT.

[mbernat]

Upon further reading and testing it seems we need to explicitly observe the relevant nodes and links, if we want to be notified about stream changes. This might be a bigger change that requires some architecting.

See the wiremix implementation for comparison: https://github.com/tsowell/wiremix/blob/d8b4a96ecb6d40d63a0bc69630d613483ae39226/src/monitor.rs#L288-L290

[SolarLiner]

Stream events and changes is something that I had in the back of my mind for a while, specifcally so that we can do things like reacting to a change in default device, or handing off to a newly-connected device. You're right that this will need some architecting to do this right, and I don't know how the APIs look like on various platforms so I haven't looked for a way to abstract them yet.