Piggy back on the Latency param change to emit a stream changed event
because we now might have a link between the stream and a device.
We should really watch for new links and emit change events for the
streams that it links to.
Fixes#3522
Let the source write into a ringbuffer when there is data available.
We then read from the ringbuffer when scheduled and use a dll to keep
the delay constant. We can later make this a driver and use the rate
correction to tweak the timeouts instead of resampling.
See #3478
For sink nodes, keep a separate device_info around for the sink and
the monitor source part of the node. Only emit changes for the sink
and monitor source part when it changed.
See #3388
Make sure don't handle names ending in .monitor as a valid sink (because
it's a monitor on the sink).
Make sure we don't return a sink (monitor) as a source accidentally but
only when explicitly requested by name with the .monitor extension.
Makes
pactl set-sink-volume alsa_output.pci-0000_00_1b.0.analog-stereo.monitor -5%
pactl set-source-volume alsa_output.pci-0000_00_1b.0.analog-stereo -5%
fail as expected.
We don't actually use this counter anywhere.
Change the counter to a mask that will contain object specific changes
to the params. This should make it possible to track what kind of
changes where done to the object and make it easier to emit the right
events later.
Tag the sink/source as HARDWARE when it's not virtual, the presence
of a DEVICE_API property is not a good check.
Make a method to check if a node is a NETWORK sink/source to make it
use the same logic everywhere.
Document the pulse.fix properties.
Add an option to disable handling of the FIX flags when the pulse.fix.
property is set to an invalid value/0.
See #3317
@DEFAULT_MONITOR@ finds the default sink but returns is_monitor true.
Always lookup the device based on the name and index. This transform
the special device names like @DEFAULT_XXX@ to the default device.
Always use the found device name as the target. Make sure to set the
CAPTURE_SINK property when dealing with a monitor.
Fixes#3284
Previously, a client disconnecting while a sample was playing could
lead to issues. For example, if a client disconnected before the
"ready" signal of the sample-play arrives, `operation_new_cb()`
would be called and that would try to use the client's pw_manager,
however, that has previously been destroyed in `client_disconnect()`.
If the client disconnected after the "ready" signal but before the reply
has been sent, then `sample_play_ready_reply()` would never be called
since operations are completed via the client's pw_manager which
would already be destroyed at that point.
Fix this by installing a listener on the client, and properly
cancelling the operation and making sure that the pending_sample
is correctly destroyed.
