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
When the follower has no buffer suggestion, it can return -ENOENT, which
should not generate an error but simply use the converter buffer
suggestion instead.
The change from 1 to 8 was done without justification in the commit
message and possibly for debug purposes. Unfortunately it breaks
negotiation with the libcamera virtual pipeline, which defaults to
4 buffers.
Set the the value to 1 again as successful negotiation - even with an
unusually low number of buffers - is usually more desirable than an
error.
Fixes: 98b7dc7c0 ("gst: don't do set_caps from the pipewire callback")
(cherry picked from commit e81fb77322)
Since 3abda54d80 we prefer the format
of the filter. This reverses the selection of the default value when
negotiating buffers from the target to the follower.
If the follower does not select a reasonable value for the buffer size,
for example, this then results in wrongly sized buffers.
Fix this by reversing the order of allocation from target to follower
where we let the target (converter) select a default value, which is
more likely to be correct.
See #4713, #4619
Don't set the UMP type flag on the format. Use the negotiated types flag
to decide what format to output. Add support for output to old style
midi.
Set the UMP type flag only on the new mixer and JACK when UMP is
enabled.
This ensures that only new (or explicitly requesting) apps get UMP and
old apps receive old midi.
This makes JACK running on 1.2 in flatpaks work with midi again.
There is no need to encode the potential format in the format.dsp of
control ports, this is just for legacy compatibility with JACK apps. The
actual format can be negotiated with the types field.
Fixes midi port visibility with apps compiled against 1.2, such as JACK
apps in flatpaks.
Only react to the capture stream state change and format changes. The
playback and capture streams change state somewhat concurrently and so
the graph state might not be consistent.
Because only the capture stream will trigger the playback stream and
start the processing, we can safely react to capture stream changes
only.
Add an index offset when enumerating controls. We insert 2 properties
before enumerating the controls so the index of the first control needs
to have an offset of 2.
The workaround is typically needed with usb-cameras using jpeg streams.
Re-enabling the skip shouldn't affect what the commit was trying to do,
i.e. fix encoded streams like h264 etc.
Fixes: bcf0c0cf8 (v4l2: only skip buffer for raw formats)
(cherry picked from commit e387772dc2)
