We don't actually need to calculate the GCD for each resampler rate
update. The GCD is only used to scale the in/out rates when using the
full resampler and this we can cache and reuse when we did the setup.
The interpolating resampler can work perfectly fine with a GCD of 1 and
so we can just assume that.
spa_alsa_read is called from the source process function when we are a
follower and no buffer is ready yet.
Part of the rate correction was performed by the ALSA driver when it
woke up but now, the resampler has updated the requested size and we
need to requery it before we can start reading samples.
Otherwise, we end up with requested samples from before the rate update
and we might not give enough samples to the resampler. In that case, the
adapter will call us again and we will again try to produce a buffer
worth of the requested samples, which will xrun.
We also need to close the SynObj fd we got, just like we close any
DmaBuf or MemFd.
Make sure we get a compiler error when we add more items to the
data type enumeration later.
Fixes#4807
A2DP v1.4 uses the rfa bits for adding 5.1 and 7.1 configurations.
Clear those bits properly when sending configuration, in case remote
device sets them.
(cherry picked from commit ae7a893ce9)
Significantly better CPU performance in lieu of canceller quality. Not
implemented for 0.x series, as there's a lot more to enable there (such
as routing modes), and I am hoping to drop support for those versions
before too long.
Ensure we have at least a `.` after `audioconvert.filter-graph`, so we
don't try to read past the end if it does not exist.
Cherry-picked from a328e0ae28, dropping
the param doc update as that doesn't exist.
Reset buffers when deactivating to avoid having old data in the
ringbuffers, which also adds latency when activated again.
Clear sink_ready and capture_ready when resetting buffers to avoid
calling process() before there is new data to process.
capture and sink streams may start before playback stream so process()
may fail to dequeue a playback buffer. In that case advance the read
pointers to avoid building up latency in the ringbuffers.
This reverts commit 46dfa69f26.
We do actually need to release the locks for now. The reason is that
pipewire core will at various points do a blocking invoke into the
thread-loop (which is the data-loop when using non-rt/async processing)
to synchronize state. Because these functions are called with the
thread-loop lock and from some other thread (like gstreamer) it causes
a deadlock because the thread-loop is locked and can't run and the
caller is waiting for the thread-loop to complete.
See #4472
Make a new alsa.use-ucm option that sets api.alsa.use-ucm on the device
it creates (when set).
There is some documentation floating around (thr arch wiki) with this
property.
See #4755
Properties of type Id should have a type of the enum with the possible
values associated with them.
The other types that don't have a fixed enumeration but are usually
mapped to some constant/description with PropInfo should be Int.
Fixes!2399
When a linked node needs to be resynced we actually never clear the
flag or reset the dll. Move the code around so that it still does
the reset of the flag and dll without actually doing the resync in
the ringbuffer when it is a linked node.
When we do_prepare, always reset the dll. We already set the alsa_sync
field but that is only used by followers to resync in some cases.
When reseting the dll, we also reset the next_time and base_time values,
we however need to do this before calculating the error in update_time
when we are the driver in IRQ mode or else we get some crazy error
that distorts the rate estimation.
Because we do the processing of the graph in the playback process
function, only do graph reset and reconfigure from the playback state
change so that we don't have process and state change at the same time
and crash.
Interrupts are disabled in alsa_irq_wakeup_event -> playback_ready method
to not produce another wakeups when waiting for a new data. Interrupts are
enabled again when a new data arrives in a method spa_alsa_write.
In rare cases, when there is multiple streams providing data and one of
them is disconnected, a new data fails to be delivered and the spa_alsa_write
is not called. Not providing data produces underrun and alsa-pcm invokes
recovery process. Recovery process starts a new playback, but without interrupts
enabled is graph not triggered and new data are not delivered (to enable
interrupts). Recovery process keeps running in loop.
Now the interrupts are enabled again after the recovery and the starvation
should not occur.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
When stream is paused, internal delay buffers were cleared, but some
data could stay in stream output queue. Without a flush, these data where
played in front of a new data.
Patch was inspired by 64d6ff4184 fixing the
same issue in a filter-chain module.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
Combine stream selects the biggest latency from all output streams and sent
the latency upstream. To select the biggest latency, each stream needs to have
the sample rate and the quantum size set.
The combine stream recalculates the latency in the latency changed callback
or during data processing.
Stream sets the sample rate and the quantum size in a copy_position call
which is normally called during processing the output data or when state
changes to streaming.
Before this change, it wasn't guarantee the copy_position was called for
each stream already and latency in the combine stream was selected from
random stream.
Signed-off-by: Martin Geier <martin.geier@streamunlimited.com>
The blocking invoke function is not meant to be called with any of the
loop context locks acquired so that it can actually run the invoke call
while blocking. Make this (and other blocking risks) clear in the
documentation.
Because it is not supposed to be called with any of the locks, we should
also not try to call the hooks (that implement the unlock/lock).
Fixes#4472
When _probe() is called, take a ref to the newly created devices instead
if sinking the floating ref, since gst_clear_object() is called when
core is disconnected. Otherwise the devices will be freed before the
caller gets them.
Fixes the following assert in the caller:
g_object_is_floating: assertion 'G_IS_OBJECT (object)' failed
Or sometimes a segfault with the backtrace:
0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x116c1b0, fundamental_type=fundamental_type@entry=80) at /usr/src/debug/glib-2.0/2.84.0/gobject/gtype.c:3918
1 0xb6d40cc6 in g_object_is_floating (_object=0x116c1b0) at /usr/src/debug/glib-2.0/2.84.0/gobject/gobject.c:3843
2 0xb6bc4c74 in gst_device_provider_get_devices (provider=0x109ba00) at /usr/src/debug/gstreamer1.0/1.24.12/gst/gstdeviceprovider.c:426
Before fixating the format, we try to add as many of the PortConfig
fields as we can as defaults. However, when we already have a property
that intersects, prefer to use the original negotiated one prefered by
the follower.
This got changed when the default for the pod filter changed to the
filter value.
The effect is, for example, when the follower asks for FL FR FC LFE SL
SR and the sink is using FL FR SL SR FC LFE, the PortConfig (and the
default) would then be FL FR SL SR FC LFE. After negotiation, we would
get FL FR FC LFE SL SR as the format but then with the filter and the
wrong default we would fixate to FL FR SL SR FC LFE, which does not
match what the follower wanted and either results in wrong channels
or an error of the follower.
See #4722
