Pass the node_data around instead of the proxy. Get the proxy from
the node data.
Allocate user_data before the node_data so that the caller can
use the proxy user_data without overwriting the node_data.
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.
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.
Don't allocate the links in an array because they might be moved
when the array is resized. Instead just use calloc and add them
to a list.
Make sure we update the list used in the real-time thread from a
safe context.
Don't pass pw_properties around when we simply need to pass around
config info, only use pw_properties when used to construct an object
that keeps the properties.
The proxy API is the one that we would like to expose for applications
and the other API is used internally when implementing modules or
factories.
The current pw_core object is really a context for all objects so
name it that way. It also makes it possible to rename pw_core_proxy
to pw_proxy later.
The pw_remote object is really a wrapper around the pw_core_proxy.
The events it emits are also available in the core proxy and are
generally awkward to use.
With some clever new pw_core_proxy_* methods and a pw_core_connect
to create the core_proxy, we can convert all code away from pw_remote.
This is a first step in this conversion, using the pw_remote behind
the scenes. It leaks into some places because it really needs to become
its own struct in a next step.
When the port receives a format, look if we can find a mixer for it
and configure it.
Use the float32 mono mixer when possible.
Use the new pw_buffers in the link.
Let the port allocate buffers between the mixer and node when
requested.
The client-node doesn't need a mixer because mixing is done on the
client.
Remove all mixer and buffer negotiation code from adapter because
it is now done at the port level.
Move fields from the io_position to io_segment. The segment contains
the mapping between raw clock time and stream time in various
formats. We keep an array of pending segments available in the
io_position field so clients can anticipate changes.
Make looping a flag in the segment instead of a state.
Prepare for segment masters. These will be registered clients that
are responsible for updating parts of the extended segment info.
Add namespace to some defines.
