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.
Clip the quantum values between absolute min and max.
If a client selected a quantum, allow this to exceed the default
quantum up to the max-quantum.
If a client doesn't select a quantum, use the default.
Add some help, version, remote options for tools
Add option for output filename in pw-profiler
Add option to start pw-cli as daemon or not, make it connect to the
default PipeWire instance by default (instead of local instance)
Only set the OUTSTANDING flag when we placed the buffer in an
io area and need to recycle it later.
When we captured a frame, put it in the queue. Then dequeue it
into the io area after recycling buffers.
Fixes#217
We only set the OUT flag when we put the buffer on an io area and
might need to recycle later.
Before placing the output buffer into the io area, recycle any
buffer that might be left in there.
Only emit the ready callback when we have some data queued.
We should not have to initialize the state to NEED_DATA, anything
that is not HAVE_DATA is good. Also we need to set the buffer to
INVALID because else it might be recycled.
