Because the capture triggers the playback stream, the playback stream
might not be actually triggered when the stream is not running.
This can cause a buffer to be queued in the capture side that is never
dequeued from the playback side. If 2 buffers are queued (and 2 buffers
are available on the stream), the capture source has no more buffers and
starts to drop/stutter.
Fix this problem by always dequeueing/queuing all the queued buffers so
that we always use the last one.
See #3276
When one side of the loopback suspends, do a EnumFormat params to force
renegotiation on the other side as well.
Suppose this:
1. sink/filter/pw-play plays at 48000Hz
2. pw-play goes away, sink and filter-sink suspend, filter-playback
idles
3. pw-play starts with 44100Hz
4. sink/filter-sink renegotiate to 44100Hz, filter-playback is still
at 48000Hz and pitch shifted.
We might want to manually suspend the IDLE nodes instead but for now
this is a good workaround.
Fixes#2969
The rt.mix_lst is really something internal to the tee and fallback
mixer in the ports so make it private.
Use the port_set_io call to add the Buffer io area to the mix_list
tee and fallback mixer on the port, like we do for remote-node. We can
then remove the custom code to do this in remote-node and impl-link.
Remove an unused field (clock) in the port struct.
Remove the unused io_set field in impl-link, it is always in sync with
the activated field.
@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
Make NTP timestamps based on CLOCK_REALTIME.
Handle socket errors.
Some devices want at least 1 second of latency between RTP and NTP
timestamps or they stay silent. A a raop.latency.ms property for this
purpose that defaults to 1 second.
It is said that all devices seem to add 250ms of extra playback delay,
so include that into the delay reporting.
Fixes#3247
Let the driver keep announcing.
Keep track of when a message was received in the driver. If we don't
receive anything for a while, reconnect.
Don't connect twide in the manager.
The module advertizes itself on multicast and will trigger a new client
in the netjack2 manager. Tested with jack2 and 'jack_load netmanager'.
The driver will receive and send data (no midi yet) from and to the
manager in sync with the manager, without resampling and with a fixed
latency.
Add a flag to the activation to mark the node as being profiled.
Only wake up the eventfd in remote-node when the profiler is running.
This keeps the server sleeping when remote nodes are driving and the
profiler is not running.
