When combine-stream initiation code was moved around in b46673b4, a
bitwise or of flags was accidentally dropped, and thus flags were
overwritten instead of added to.
Set the corked state on streams so that we can use this in sink-input
and source-output info without guessing.
The problem is that when a stream starts un-corked, the state is less
than RUNNING and so before this patch, pulse-server reports a corked
stream, which is not what pulseaudio reports.
When we receive a message with fds and we are at the end of the
buffer, we will call clear_buffer, which moves the next fds over the
fds of this message before we copy the fds into the message. This
results in the fd being leaked and the message using the fd of the next
message instead.
Avoid this by first copying the fds into the message and then move the
new ones over the old ones.
This fixes some wrong fds being used by clients.
In line also with da8e207de9,
make sure that the rtp-sap receive socket listens only to the configured
sap.ip in unicast mode, instead of accepting all packets on the port.
This additionally fixes breakage that was inadvertently introduced in
f2f204d604. Because the
`struct sockaddr_storage *sa` argument in `make_recv_socket` points
to `impl->sap_addr`, changing the address to INADDR_ANY in the unicast
code path would also silently cause the sender socket to try to
connect to INADDR_ANY and fail.
The "connection" address ("c=") is meant to be the address that the
RTP receiver will use to filter for incoming packets. In multicast,
it must be the multicast address, which is also the "destination"
address in this context. In unicast, however, it must be the sender's
address, i.e. the "source" in this context. The RTP receiver will
then call connect() on this address, effectively filtering the incoming
packets to the ones coming from that particular source.
Allows us to get error counts and occasional samples, which can be handy
if we are CPU-bound. There is room to improve this by having
module-profiler create aggregates, which might be more useful that
periodic instaneous samples. However, this would need more logic to
store node data in between emissions, so we'll punt that to later.
Make `client_queue_subscribe_event()` take the facility and type
separately, and calculate the mask itself, so that the caller
does not need to be concerned with that.
Make a function that can initialize raw audio info from a dict and fill
in the defaults. We can use this in many of the modules when the audio
format is parsed.
Use the helper instead of duplicating the same code.
Also add some helpers to parse a json array of uint32_t
Move some functions to convert between type name and id.
This gets the next key and value from an object. This function is better
because it will skip key/value pairs that don't fit in the array to hold
the key.
The previous code patter would stop parsing the object as soon as a key
larger than the available space was found.
Add spa_json_begin_array/object to replace
spa_json_init+spa_json_begin_array/object
This function is better because it does not waste a useless spa_json
structure as an iterator. The relaxed versions also error out when the
container is mismatched because parsing a mismatched container is not
going to give any results anyway.
Intercept the Output Latency paran and parse it for later.
Use the computed latency as the ProcessLatency and expose this
as the ProcessLatency param and the updated Input latency.
Accept updates to ProcessLatency to modify the latency, which then also
updates the Input Latency param.
See #4270
Improve the Latency reporting, we always report Input and Output latency
pairs.
Keep ProcessLatency on the capture and playback streams. The capture
stream process latency is reported as input latency and the playback
process latency as output latency.
Setting ProcessLatency on the capture stream (Sink), for example, will
propagate the added latency upstream. This would then instruct players
to send the audio earlier to compensate for the delay.
See #4270
Instead of binding the socket to 0.0.0.0 with port 0, make some config
options source.ip and source.port to configure this. This makes it
possible to bind to other interfaces or to use a fixed port for the
data messages.
Fixes#4144
Our current AES67 sender setup requires that that PTP driver drive the
entire graph. This adds support for allowing the AES67 RTP sink to be
driven by an arbitrary driver, while still using the PTP driver for
sending data on the network.
When aes67.driver-group is specified a pw_filter is created with no
ports, node.always-process = true and node.group set to the
aes67.driver-group. When set to PTP, this gives us process callbacks at
the PTP rate which we use to get the current PTP time in the RTP sender
by interpolating the clock snapshots from the pw-filter.
Implementation ideas from Wim Taymans. Co-authored with Sanchayan Maity.
For a detailed reference, refer the following papers by Fons Adriaensen.
- Using a DLL to filter time
(https://kokkinizita.linuxaudio.org/papers/usingdll.pdf)
- Controlling adaptive resampling
(http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf)
We allow a quantum of jitter in the write timestamp. The previous value
of 32 seems to be empirically determined, using the actual quantum
allows us to reason about this better.
When the combine-stream module is used as a source and the input streams
are overlapping, mix the samples instead of overwriting the previous
samples.
See #3710
Avoids need for additional configuration to allow disabling send (which
in turn was needed to avoid errors when a network interface is not
available on start).
In circumstances where the network interface is not ready yet,
creating a send socket will fail. This may be ok if we only
intend to use rtp-sap as a listener, therefore add an option for it.
Only set use the graph rate and duration when the ffado.sample-rate
and ffado.period-size properties are set to 0. Othersize use the
configure values.
Without this patch, it would just ignore the settings and always use the
graph rate.
