dup the fd when added to the outgoing buffer and close it againç
when sent. This ensures the fd remains valid in the buffer. A
quick add/remove of memory before a buffer flush could close the
fd before we can send it and then we get a bad fd and disconnect
the client.
Remove the extra proxy to the node, it's awkward and not needed.
pw_core_export() returns a handle to the remote object with the
interface of the factory.
If the node is destroyed, make sure the proxy doesn't access
it anymore.
If the handle is removed or destroyed, make sure we remove the
proxy related info around the node. Never destroy the proxy
ourselves, this is something the app needs to do when it is
ready.
When the proxy is destroyed, suspend the node before we start
removing the memory or else the node might still be using it from
the data thread and crash.
Ownership of the node_resource is taken by _new() and freed.
Don't try to use it afterwards to send an error when something
goes wrong but use the original resource.
When the resource does add_listener, send a message to the proxy
to trigger an emission of properties.
Block the client until all properties have been notified, track
this with a ping event to the implementation.
Abuse the xrun callback in the adapter to emit the drained signal until
almost all data left the resampler. This needs more work with a proper
signal and a buffer flag to signal the drain.
The info structure needs to be cached because there is no way to
request it from the implementation, unless we hack the add_listener
API to be used for making info requests or add a new method that
will be used just in the implementation (both are bad ideas).
The params are cached because
1) a client doing enum_params + sync will not work correctly, since
the sync call syncs with the server and not the implementation...
we could block the client to solve that, but then there is also #2
2) the implementation is not aware of the clients and therefore
it cannot keep track of who is subscribed and who is not, this
needs to happen in the server. Then if we only keep track of the
subscriptions in the server and keep requesting params from the
impl, there is no way to know if a param event coming from the
impl matches a call to enum_params or to subscribe or if it's
just an update that needs to be forwarded to subscribers.
