On some device combinations (MT7925 / Sony LinkBuds S) the low-latency
48 kHz QoS crackle.
It's probably better to default to high-reliability for those, until we
have proper quality vs. latency configuration in place.
Socket activation uses sd_listen_fds from libsystemd, and can only be
compiled on systems with systemd.
This is an issue for Alpine / postmarketOS, where upstream has no
systemd package, but downstream depends on upstream's pipewire package
and wants to rely on socket activation. This also prevents using
socket-activation on other non-systemd distributions, including
non-Linux.
Implement equivalent functionality without a dependency on libsystemd.
sizeof(adapter) is larger than the big_entry->adapter and so the code
would copy too much. Instead only copy the strlen of the parsed
adapter, which we checked above to be smaller than the available size.
This doesn't copy the 0 byte because the memory is assumed to be 0
filled already by the calloc.
If the address is exactly the HCI_DEV_NAME_LEN, it will result in a non-0
terminated string, which may or may not be a problem...
This can easily be overlooked if the RTP rate equals the clock rate, which
is fairly common (for example, RTP rate and clock rate both being 48 kHz).
And, if an ASRC is active, and converting the output of the RTP source
node, the resampler's delay need to be taken into the account as well.
Clear the ringbuffer in stream_stop() when processing stops to prevent old invalid packets
from being sent when processing resumes via rtp_audio_flush_packets().
This ensures a clean state when the stream restarts.
Clearing the ring buffer is important not only in the direct timestamp
mode, but also in the constant delay mode, since missed packets can lead
to gaps in the ring buffer. These gaps may have stale data inside if the
ringbuffer is not cleared after reading from it.
In corner cases where the read and write pointers are very close, it may
not be possible to read out all the wanted samples. This can for example
happen when there is a jump in the graph driver position. Currently, the
code reads the wanted number of samples out of the ring buffer regardless
of the write and read pointer positions. It does so even when the read
pointer is ahead of the write pointer (that is, an underrun occurs).
Fix this by checking the fill level and reading only the available amount
of samples if that amount is less than the wanted amount. The remaining
space in the target buffer is then filled with nullbytes.
This reverts commit dcdc19238b.
Reverting this because it caused big sync errors of ~62 ms in test setups.
Further discussions about this can be found here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2666
Followup commits modify the device delay application (by scaling it),
which is another reason why this needs to be reverted.
Previously the override was only present in `cc_flags`, meaning that
C++ source files, like `aec-webrtc.cpp`, would not have it.
Fixes: 6d74eee874 ("spa: bump channels to 128 again")
Add 35 sec timeout for PLAY_SAMPLE streams to start streaming, similar
to what we do with normal streams, and fail playback if they don't
start.
This avoids pending sample playback using up resources indefinitely if
streams fail to start for some reason, e.g. session manager is not
linking them.
If we get EPROTO, we likely have missed on some messages from the
server, and our state is now out of sync.
It's likely we can't recover (e.g. if error is due to fd limit hit), so
just drop the server connection in this case, similarly as if we got
EPIPE.
By setting the hci handle (e.g. hci0) of the desired adapter, the BIG
config will only applied on that adapter. In case no "adapter" entry in
the config is given, it will be applied on all adapters.
Signed-off-by: Alexander Sarmanow <a.sarmanow@televic.com>
Commit 2942bae034 introduced parsing of
"SupportedFeatures" which uses a third DBusMessageIter pointer.
*** stack smashing detected ***: terminated
==389050==
==389050== Process terminating with default action of signal 6 (SIGABRT)
==389050== at 0x4F57B2C: __pthread_kill_implementation (pthread_kill.c:44)
==389050== by 0x4F57B2C: __pthread_kill_internal (pthread_kill.c:78)
==389050== by 0x4F57B2C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
==389050== by 0x4EFE27D: raise (raise.c:26)
==389050== by 0x4EE18FE: abort (abort.c:79)
==389050== by 0x4EE27B5: __libc_message_impl.cold (libc_fatal.c:134)
==389050== by 0x4FEFC48: __fortify_fail (fortify_fail.c:24)
==389050== by 0x4FF0ED3: __stack_chk_fail (stack_chk_fail.c:24)
==389050== by 0xBC1D1A1: remote_endpoint_update_props (bluez5-dbus.c:3137)
==389050== by 0xB53609F: ???
==389050== by 0x1DF: ???
==389050== by 0x61C17BF: ??? (in /usr/lib/x86_64-linux-gnu/libdbus-1.so.3.32.4)
==389050== by 0x1DF: ???
==389050== by 0xC5ED113: ???
Replace magic numbers (0x02, 0x05) with named constants BT_CODEC_CVSD
and BT_CODEC_MSBC for better code readability. Also remove redundant
zero initialization of num_caps field since the buffer is already
memset to zero.
The sco_offload_btcodec() function now returns void and only skips
offload setup when using the default datapath, simplifying the logic
and removing the need for explicit feature flag checks.
Add support for configuring the SCO hardware offload data path for
HFP/HSP profiles using the Bluetooth SIG-specified procedure. This
enables vendor-specific SCO offload integrations.
Changes:
- Add `bluez5.hw-offload-datapath` configuration property (default: 0)
- Implement `sco_offload_btcodec()` to set BT_CODEC socket option
- Add `SPA_BT_FEATURE_HW_OFFLOAD` quirk feature flag
- Apply offload configuration when creating SCO sockets if quirk enabled
- Document new property in pipewire-props.7.md
The datapath ID is configurable via device parameters and only applied
when the hardware offload feature flag is set in quirks, allowing
platform-specific SCO offload implementations.
The simple formats contain some common mappings for other extensions such
as mp3.
Makes pw-record test.mp3 actually write an mp3 instead of a wav file.
Clamp the control values to their min/max.
Remove the default_control array, we can just restore the default with
the port_set_control_value(). Do this when no value has been set on the
port when we set up the graph. The avantage is that we calculate the
default, min and max correctly when they depend on the graph rate.
Fixes#5088
Since commit a1f33a99df changed buffer handling to create new GstBuffers
instead of reusing pool buffers, the video crop metadata was silently
lost. The code used gst_buffer_get_video_crop_meta() which returns NULL
on a fresh buffer, so the crop values from PipeWire were never applied.
Change to gst_buffer_add_video_crop_meta() to actually attach the
metadata to the buffer.
Also remove the now-obsolete call in gst_pipewire_pool_wrap_buffer.
This was discovered when using the XDG Desktop Portal's RemoteDesktop
interface: the full desktop was being delivered instead of just the
selected window, because the crop region metadata was not being
propagated to the GStreamer buffer.
Fixes: a1f33a99df ("gst: dequeue a shared buffer instead of original
pool buffer"), from merge request !1258
CC: @jameshilliard
When the graph has no inputs and the channels is set to 0, don't create
a capture stream. Likewise, don't create a playback stream when there
are no graph outputs and the output channels is 0.
You can use this to make a sine source or a null sink.
There is no reason to fail when there is no input or output port.
We can simply run the graph with what there is. Even if there is no
input or output at all, running one instance of the plugins is
possible.
Add a busy builtin plugin that has no ports and keeps the CPU IDLE or
busy for the give percent.
The filter graph has, after parsing, a default number of input and
output ports. This is based on the description or the first/last element
input and output ports. Pass this information in the properties when
we emit the info.
Don't use the number of configured input/output ports as the default
number of channels in filter-chain because this is only determined after
activating the graph. Instead, use the default input/output channels.
The result is that when you load filter-chain without any channel
layout, it will default to the number of input/outputs of the graph
instead of 0. This allows for the node to be visible in the pulseaudio
API.
Fixes#5084
Don't rely on the out_rate vs n_phases to decide on when to use the
inter resampler because the out_rate can change when we activate the
adaptive resampler.
Instead use a boolean that we can set at the start.
