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.
Because we keep everything in a ringbuffer and provide exactly the
required amount of data, we can use 1/4 buffers.
Also increase the buffer size. We don't want to limit the buffer size
to the negotiated tlength because it can be increased later. Instead
scale it to the max quantum size (8192) with a max resample rate of 32.
This reverts commit 1b94b66924.
It causes problems with qemu.
Without this patch, paplay --latency-msec=1 /some.wav hangs when
forcing the quantum to 8192. A different fix will be needed.
When we increase the quantum past the tlength, we need to be able to
ask for more bytes than the tlength or else we will never exit this
underrun state. Look at the last required bytes and use that if it's
larger then tlength.
If we are underrun, don't update the read pointer and let the write
pointer catch up.
If we don't have enough data to fill a buffer, skip all the available
data and wait for the new request to arrive.
Fixes#1857
Make the pulseaudio layer set the PW_KEY_STREAM_CAPTURE_SINK property
when a monitor device is selected as a source to make it easier for the
session manager to find the right source.
Drop client connections when pipewire goes away. pipewire-pulse daemon can remain running and pulseaudio clients will be able to connect again once pipewire is up and running.
Reorganize the latency setup in one place, return a desired device
latency for use as quantum.
PulseAudio assigns half of the (tlength - minreq) latency to the sink
but we can't do that because our sinks have a max-quantum of latency.
Fix this by clamping our calculated sink latency to the quantum
PulseAudio subtracts the sink latency from the tlength in adjust latency
mode, so we need to do the same.
This makes PULSE_LATENCY_MSEC values bahave more like pulseaudio.
See #1769
Make things work then there is no default input device and the default
source is actually the monitor of the default sink.
Also implement lookups of monitor sources with the monitor id as the
name.
Fixes#1691
Use the core.info clock rate as the default sample rate as soon as the
manager exposes the core object. Otherwise the default sample rate is 0
until someone calls GET_SERVER_INFO, which as a side effect sets the
default sample rate.
Fixes issues with sinks not appearing right away.
Fixes#1588
Audio with big frame sizes (especially audio with multiple channels) needs more
buffer size than the one calculated with the current formula. This patch uses
the frame size to calculate the buffer size, fixing playback issues for clients
configured in passthrough mode.
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.
Virtual devices tend to start with partial fields set in the EnumFormat
param (usually rate is missing). This causes virtual devices to be
invisible until they are used in some way.
Fix this by relaxing the parsing of EnumFormat and by falling back to
the server defaults for the unspecified fields.
Fixes#1413
Set node.target metadata to "-1" instead of deleting it to direct nodes
to the default device.
Deleting the metadata, as done previously, does not work for nodes for
which the client has node.target set.
Add a simple quirks table.
Forces S16 formats for teams sink and source info.
Forces removal of the DONT_MOVE flag for capture streams for firefox.
See #838 and #1363
When a sink is RUNNING but there is nothing linked to the input it must
be the monitor that is keeping it active, report IDLE for the sink in
that case.
When a source is RUNNING but there is nothing linked to the output it
must be the sink part that is keeping it active, report IDLE for the
source.
Fixes#1345
