Collect all timing info in the process function. When doing delay
reporting, get a consistent snapshot of all the pipewire side state to
calculate the result.
This should result in more correct timing results.
Only subtract the elapsed time from the server delay. Our reported
delay should always at least still include the data that we have
buffered or else read and write operations might think they can read
or write more than they actually can.
There is no need to patch the pw_time values with the io->rate just so
we can use it to convert the elapsed time to samples. Use the io->rate
directly instead.
Make the receiving state machine more pronounced by explicitly storing
the state in the client. Furthermore, always consume the message content
if there is one and not only if the content type is "application/octet-stream",
but do not try to do it at once - like previously, instead only as the
socket becomes readable. The body is currently dropped, but it could
easily be collected in e.g. a `pw_array` should the need ever arise.
See #2673
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
