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
Based on patch from Barnabás Pőcze <pobrn@protonmail.com>
Instead of trying to keep track of the missing bytes ourselves, use the
simple tlength - avail - requested formula to request more bytes from
the client.
Fixes#1981
Only call `spa_list_remove()` in `stream_free()` if the
stream is pending. `spa_list_remove()` does not reinitialize
the list node, therefore calling `spa_list_remove()` again
after the stream has been removed from the pending list
will corrupt the pending list of the client.
Always reevaluate the tlength or total buffered samples when the
quantum changes, even for the first sample because it is possible that
we completely miscalculated the length when we started, like when the
quantum is force high and the requested latency is low.
Also only increase the calculated tlength, for smaller sizes we don't
need to do anything, we can keep the latency as is it.
See #1930
Keep track of the current quantum and recalculate the tlength in the
same way that pulseaudio does.
Send a bufferattr changed message to a client when we change the
parameters.
This fixes the case where the quantum is increased and there needs to be
more buffering to keep the stream going.
When the client adapter is configured in passthrough mode, the stream param
changed event in pipewire-pulse is emitted before the session manager creates
the link, and not after. Therfore, the peer can never be found when replying
create stream, and the pulseaudio application receives a stream error.
This patch delays the create stream reply until the link is added if the peer
cannot be found, fixing the above race conditon to allow passthrough mode to
work with pulseaudio applications.
If a log message is rate limited, we only need to know about it if we
are actually interested in that log level. We therefore add an argument
to the ratelimit_test function to set the log level of the message
printed if a message is skipped
Change-Id: I5ccd4a78bf7e972fe8b0e7133cd7e08c1e38835f
