This was introduced in 4faa28fd96 in order to correctly map the time
from the stream. From d52df30c88 on, however, the clock switched to
monotonic time, which does not need the extra-offset.
Disable `clock_reset()` for now but leave it in place so we can easily
reenable it once we use the stream time again.
This fixes video recording in Cheese and similar apps.
Closes https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3149
Use the "high-reliability" values for QoS parameters instead of the
low-latency ones. Under some condition BlueZ does not pass on the
endpoint QoS values to us, in which case we may end up selecting bad
latency.
Determine correctly if we are resampling, and have the associated delay.
Add off-by-one sample adjustment to the resampling delay, which seems to
correctly align the resampled audio with non-resampled.
A non-passive link between the driver and itself should make the driver
active as well.
This makes the midi-bridge running when linking its ports. It also activates
a sink when its monitor ports are connected to its playback ports.
Fixes#3153
Make the channels configurable for capture, source, playback and
sink streams. The playback and sink stream need to have the same number
of channels but the layout can be different.
Use init2 of the echo-cancel plugin when available to pass this info
around. The echo-canceler will then further adjust the settings to make
things work.
The WebRTC echo canceler can support different rates and channels for
the record, out and playback streams.
Add a new method to pass this config to the echo-canceler.
Explicitly make the driver runnable when we add a runnable node to it.
We have to do this because the runnable node might not be directly linked
to this driver.
In the case of the echo-canceler, for example, a playback stream
can be linked to the sink before the echo canceled virtual sink.
All echo-cancel nodes are added to a source driver, which would not be
activated because there is no direct path from the playback stream
to the source river.
Fixes#3145
Resynchronize ISO streams on playback (re)start, so the stream positions
are aligned immediately. This is better than relying on rate matching
to correct any offsets.
Use a separate variable to hold the maximum amount of drift we allow
between driver and follower. Ensure this value is smaller than the max_error
and period size so that we have at most 1 period of drift.
Don't reschedule a timeout when we have less samples available than the
target but only reschedule when we have less that the required amount we
need to read. This ensures that we hover around the target level and the
timeouts/rate matching adapts correctly. Previously we would only rate
match if the have at least the target amount of samples, which would
then always result in a possitive rate adjustment and cause drift.
For capture, make sure that there is at least 32 samples of headroom
when we are not using IRQ mode to handle jitter in the timer wakeup.
For capture of batch devices this results in (for a 1024 quantum) a
target buffer fill level of 1024 + 512, and we will read if there are at
least 1024 samples available.
For non-batch devices we aim for a target buffer fill level of 1024 + 32
and read if there are at least 1024 samples available.
Emit BAP device set nodes, which the session manager can use to combine
the sinks/sources of a device set to a single sink/source.
Emit the actual sinks/sources with media.class=.../Internal to hide them
from pipewire-pulse.
Add separate device set routes to the set leader device. Other routes
of the set members will be marked as unavailable when the set is active.
Accordingly, return failure for attempts to set these unavailable
routes, so that volumes etc. of the "internal" nodes are only controlled
via the device set route.
For ISO server sockets, the QOS struct from getsockopt contains values
with different meaning from ISO client socket. Get the values via DBus
instead, which is right in both cases.
If BAP codec configuration is mono channel with unspecified location,
set the channel position from transport location.
This in principle should be set in SelectProperties, but currently BlueZ
doesn't tell us that yet there, so we hack it up later on.
The number of channels is determined by Audio_Channel_Allocation.
One frame block contains all channels. (BAP v1.0.1 Sec. 4.2)
Fix the handling of frame blocks and counting of numbers of channels. We
support and configure only one frame block per packet.
Consider omitted Audio_Channel_Allocation to indicate MONO stream (see
BAP v1.0.1 Sec 4.3.2).
This is a follow-up to d5390c7, where we switched to the 'PCM' mixer controls
on Sound Blaster Audigy devices, since the ones we used before only work in the
stereo-to-all-speakers mirroring mode.
It turns out we do use that mode after all, but only in a couple of profiles.
Since returning those profiles to the default mixer path yields uneven volume
steps similar to #2934, we instead add a new mixer path just for that mode.
Creative Labs Sound Blaster Audigy cards (snd_emu10k1 driver) expose
mixer controls named 'PCM Front', 'PCM Rear', etc. in addition to the
more common 'Front', 'Rear', etc. The latter seem to be intended for
a stereo-to-all-speakers mirroring mode that we do not use, and have
no effect when we adjust them.
https://docs.kernel.org/sound/cards/audigy-mixer.html
We therefore define a custom mixer path for Audigy devices, using the
PCM mixer controls.
This has been tested on an Audigy 5/Rx. Based on a brief look at the
ALSA driver, I think all Audigy devices (vendor 0x1102, device 0x0004
or 0x0008) have the same PCM controls, making this change probably safe
for our existing Audigy udev rules.
Relevant kernel files:
sound/pci/emu10k1/emu10k1_main.c
sound/pci/emu10k1/emufx.c
include/sound/emu10k1.h
Fixes#2934
The raw biquad takes its values from the config and then updates the
control ports with them in activate. At runtime, the changes to the
ports are applied to the biquad.
Other biquads take values from the config ports in activate.
When the timing_port is 0, just don't send out an initial timing packet.
When we receive a timing packet, reply to the same address/port that the
timing packet was sent from.
Fixes#3133
