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
Clear the READ flag when the param is removed.
Don't recursively emit param_changed events or we could end up in an
infite loop when we update params from param_changed.
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.
Clear the callbacks from the processing thread to avoid races.
Check the callbacks in the processing thread before calling them,
we just need to check if there are functions, we checked the method when
installing the function.
Fixes#3251
@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
On musl, `pthread_t` is a pointer type, so printing it
as a long generates warnings. So cast it to `void *`
and print it with "%p" since it is actually a pointer
even on glibc (nptl) (at least at the time of writing...).
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
Use snd_pcm_htimestamp to get both the available space and the timestamp
when this was calculated. We can then use this to get a better estimate
of the delay in the device against the graph start and get a more
reliable delay between capture and playback.
Use separate values for the number of available samples in the
ringbuffer and the delay in the device.
When using htimestamp we can use the tstamp to get a more accurate delay
value against the graph start time.
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.
