EAC3 needs to be opened in 4x the rate of the EAC3 stream, which can be
32, 44.1 or 48 KHz. Some clients already multiply but others don't.
Check here what is the case and fix it up.
Fixes#1902
Only update the quantum/rate when we have a pending change.
This works around a bug in sco-source that changes the quantum
by itself but in any case, this optimization is nice to have.
See #1905
When moving a driver to another, move the quantum and rate to the
current_ fields so that they are applied when the next cycle starts
instead of during the cycle.
The `pw_*_info` structures in core pipewire all have 64-bit change
masks. Convert the change masks in the session manager extension
to 64-bit as the differing sizes can cause problems.
This introduces an API and ABI break unfortunately, but due to
the limited number of users of the session manager extension,
it was deemed safe.
See wireplumber#49
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.
As per JACK API description the call to jack_deactivate should
disconnect all ports because an inactive client can't have connections.
This disconnect is missing in the current API and results in left-over
links after the call and malfunction to clients (e.g. Music Player
Daemon).
To fix it this commit goes through the list of links to owned ports and
disconnect them.
Signed-off-by: Hendrik Borghorst <hendrikborghorst@gmail.com>
Only update the quantum/rate when we have a pending change.
This works around a bug in sco-source that changes the quantum
by itself but in any case, this optimization is nice to have.
See #1905
When moving a driver to another, move the quantum and rate to the
current_ fields so that they are applied when the next cycle starts
instead of during the cycle.
The `pw_*_info` structures in core pipewire all have 64-bit change
masks. Convert the change masks in the session manager extension
to 64-bit as the differing sizes can cause problems.
This introduces an API and ABI break unfortunately, but due to
the limited number of users of the session manager extension,
it was deemed safe.
See wireplumber#49
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.
Handle 1 channel as a mono channel, which gets copied to all outputs
or gets the average of all inputs.
Fixes the case where a mono channel is handled like a FRONT channel
and then gets attenuated when mixed into left and right.
When pipewire is accessed through the portal camera API then only the
camera node objects are visible for the client.
However, chromium wants to know the vendor and device ids to identify
cameras. And those properties are currently only added to the device
object.
Fix this by propagating the ids to the node object.
Fixes#1879
