Previously, the state used to receive messages from the remote
end was not reset when the client connected, which could
lead to issues if the same client is reused for multiple
connections.
Previously, the content had to be a null-terminated byte
sequence because the sending function used `strlen()` to
determine its length. However, `rtsp_do_auth_setup()` needs
to send a non-textual byte sequence, and it only worked so
far because it did not happen to have any zero bytes in it.
Add a "content_length" parameter and change the type of
"content" to facilitate sending arbitrary byte sequences.
The commit cited below mistakenly removed the set_rlimit call from under
`if (impl->use_rtkit)`, saying it doesn't have an rtkit implementation.
However, this function does call rtkit, so it has to be called in the
rtkit flow, otherwise pipewire fails to set the realtime priority,
printing the following error message:
mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
mod.rt: could not make thread #### realtime using RTKit: Permission denied
Fixes: 5ae1c03d77 ("module-rt: small fixes")
Only activate the input links to a node after the node has been added to
the graph.
This ensure that we don't accidentaly schedule the node before the Start
command has completed and the node is actually ready to process data.
The Start command might be async and we should not schedule the node
until the reply has arrived and we have actually added the node to
the graph.
Otherwise it is possible that the node is scheduled before it could
complete the start command. This could be a problem for adapter because
it does negotiation and so on in the Start call.
See #2677
When a client writes more then requested, let the requested field go
negative so that it is taken into account the next time we ask for more
data.
Also the requested field follows the difference in the write pointer
caused by seeks.
See #2626Fixes#2674
DSD64 would be a rate of 44100 * 64 / 8. When packed in U32_BE, we would
negotiate 44100 * 8 / 4 (88200) with the device, this means all rates
from 88200 and up are allowed for DSD64 in U32_BE.
A client can sometimes send more data than we requested. PulseAudio
keeps the extra data around, it just asks for more data when it consumed
some of it.
PipeWire however always tries to keep tlength worth of data, as
specified in the PulseAudio docs... Keep track of how much extra data
has been sent and keep this around as well. Make sure we flush this
extra data as well.
Fixes#2626
Although pos will be set to 0 in the first iteration, the compiler does
not seem to figure this out, so help it a little:
../spa/include/spa/support/log.h:306:21: warning: ‘pos’ may be used uninitialized [-Wmaybe-uninitialized]
306 | pos += sprintf(str + pos, "%02x ", buf[i]); \
| ^~
../spa/include/spa/support/log.h:301:13: note: ‘pos’ was declared here
301 | int pos; \
| ^~~
The stream only has one format/enumformat list for the one port it has
so also expose this on the node. We can then remove the adapter for
video.
We can also now show midi (control) streams as the format in pw-top.
Add a column with negotiated formats.
It requires an adapter that will enumerate the port formats so it does
not work for video streams yet.
Fixes#2566
Move the latency fraction calculation to fix_ functions so that the
new latency rate can be used when creating the streams.
Actually set the requested record attributes on the stream instead
of modifying the defaults.
See #2671
3f6fe392 uses headers from /usr/include/lv2/atom/. but this leads compilation
failure for some distros (i.e. ubuntu 18.04) as they have some
different location for these headers. One can find these headers
at /usr/include/lv2/lv2plug.in/ns/ext/atom/ (for ubuntu 18.04)
instead /usr/include/lv2/atom/. So guard them with __has_include.
and mention other possibilities.
Fixes#2670
