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
Add check for running the the loop context and thread.
Add checks in filter and stream to avoid doing things when not run from
the context main-loop because this can crash things when doing IPC from
concurrent threads.
Rework the runnable state calculation. It works in 2 steps now:
1. Collect all nodes linked to a driver in some way. Mark nodes that
are reachable with a non-passive link as runnable.
2, Go through all runnable nodes and set all linked nodes to the
runnable state as well, up to the driver.
Step 2 is new. Previously if there was just one runnable node, *all*
nodes would be set to runnable. With the addition of step 2, some nodes
might remain idle when they are not used.
This has the effect that virtual sinks without inputs stay idle when
the driver is otherwise running. Grouped nodes (like the RTP session)
will now also only run the linked nodes.
