spa_exchange() is used in spa_clear_ptr() and spa_clear_fd() which
already use the _old_value variable. So make it use a slightly different
local variable name to avoid shadow warnings.
Fixes#3915
spa_json_parse_stringn() can be used when the strings source and
destination are overlapping so use memmove instead of strncpy to
avoid corruption of the strings.
Use snd_ctl_card_info to set some more card properties such as the
alsa.id, alsa.mixer_name and alsa.components.
alsa.id is interesting because it is possible to use udev rules to set a
custom id, which is handy when you have two identical cards in the
system and want to assign unique ids to them.
See #3912
This does a couple of things: first, we implement revents demangling,
which seems to be required (although hw: devices work fine without it).
The second is to actually read the ctl events so we can tell when
elements we care about have changed, instead of reading everything and
trying to do a diff.
The latter is also required from a correctness perspective, as otherwise
the ctl might keep triggering wakeups while the fd is ready to be read.
Add a monitor.passthrough option. This will pass all latency information
directly between the port and its monitor ports.
This is interesting when the adapter (and audioconvert) is used with a
null-audio-sink that simply forwards the data to a real sink/souce. In
that case, we want the sink/source latency to be passed unmodified.
Set the monitor.passthrough on the pulseaudio null-sink because
a passthrough virtual sink is the most likely use case for this.
Add some monitor.passthrough default config where it makes sense.
Fixes#3888
Currently the HDMI output paths have jack mixers named "HDMI/DP" and
with append-pcm-to-name=true. However, most of the SOC audio drivers
are just named "HDMI" and don't add the ",pcm=N". Add these alternate
jack names to the HDMI audio path files so that jack detection will work
on these SOCs.
Keep track of the valid ports and don't emit port info for
invalid ports. When a listener is added while the ports are being
created, it is possible that the ports are still NULL or invalid.
Propagate the error if spa_system_eventfd_create() fails. Also copy
errno before calling spa_log_debug() in spa_system_eventfd_create() to
make sure it is not overwritten.
The rate we get from dlls can have a subsample precision. However,
the check for using process_copy is in sample precision. This means
that an adaptive stream will oscillate rather then lock into the
exact rate.
We would timestamp within an unlikely block, which would introduce
additional jitter to current_time, which would have an impact on
the performance of the timer sensitive code.
Add a MAPPABLE data flag that hints that the fd in the data is mappable
with a simple mmap/munmap. Normally, DmaBuf is not mappable like that
unless explicitly indicated with this flag.
Set the MAPPABLE flag on the DmaBuf from v4l2 and libcamera fd.
When asked, mmap the buffer memory in all cases when the MAPPABLE
flag is set.
This solves the case where v4l2 has exported DmaBuf and is streaming to
node A and then node B links but doesn't get automatically mmaped
memory.
Fixes#3840
Always reevaluate the rate matching even when we did not change the
follower state.
It is possible that we were a follower from some node with the same
clock and now become a follower of a node with a different clock. The
follower state doesn't change but we need to activate the rate matching
logic in that case.
Fixes rate matching in pro audio (playback) when capture and playback
are moved to another driver.
After we set the format, probe if we can do EXPBUF and enable/disable
the ALLOC_BUFFERS flag on the port.
This should gracefully handle the case where EXPBUF is not available.
Fixes#3821
When we try to alloc buffers but EXPBUF is not supported, make sure to
clear the alloc_buffers flag so that the caller can try again with
allocated buffers instead.
See #3821
Move some of the tracking code for the DLL to where it is used.
Add resync.ms (default 10) option at which we give up rate adjusting
and instead do a hard resync. This results in a jump in the position
of the graph clock.
We can increase the MAX_LATENCY again if we increase the amount of
buffers when we are using a small buffer.
Normally we ask for 4 * quantum-limit as the buffer. This should be good
to use 1 buffer and quantum-limit as the quantum with enough headroom
to not run out of buffers.
If we are however using less buffer-frames we need to be careful and
allocate an extra buffer. Imagine using a buffer of 4096 frames, we can
support a quantum of up to 2048 frames if we use 2 buffers.
See #3744
Half of the buffersize is not enough to support as a max-quantum, we
need to divide by (4 * frame_scale) to allow some headroom and account
for the DSD scaling. We do the same calculation to suggest a buffer size
using the quantum-limit.
See #3744
When the filter has no format property, just enumerate all possible
framerates. Handle error case where the filter has the wrong type.
Makes gst-launch gstpipewiresrc ! video/x-raw ! fakesink work.
See #1793
Actually count the number of frame fractions we add. If we added 0, we
don't have any supported framerate that intersects with the filter and we
try the next frame size.
See #1793
Unknown transports visible in DBus usually belong to a different
sound server instance that is talking to BlueZ.
Explain this in the warning message that we log, so that people can more
easily understand why things are not working.
When freewheeling we will immediately schedule a new graph cycle when we
get a process call because the graph completed.
When the process call is not done, because of some xrun or
because some node was removed that causes the graph to fail completion,
The next cycle will happen after a timeout.
This timeout was calculated as the ideal wakeup time (after a quantum of
time) and would accumulate for each timeout. The result is that the
timeout ended up far in the future and would stall the freewheel driver
for a long time.
Fix this by always setting the next timeout to wakeup time + freewheel.timeout
seconds. Also add a config property for the timeout (10 seconds, like
jack2 by default).
Primark True Wireless earbud doesn't support sbc-xq. Having it
enabled causes bluez to enter into a loop enabling/disabling
the device dozens of times per minute, making it unusable.
As part of the setup for IRQ based scheduling, a period event
was installed. Not only is a timer based polling unecessary for
IRQ scheduling, depending on the state of the system, the timer
could fire far enough from the IRQ, causing alsa wakeup events
with no data in the ring buffer. Pipewire would identify these
events as an "early wakeup", adding an extra quantum of time
to the next_time estimate, skewing the clock and causing issues
with apps that depend on precise timing.
Update the started and ready state after we suspend/pause the node so
that we don't complain if scheduling happens between setting the fields
and actually stopping the follower.
Also only complain when the scheduling happens when the node is not
ready. It is possible that the node is scheduled before we manage to set
the started field.
Move the driver and warned bits after the int field in the struct so
that they are placed in separate memory.
Otherwise, a write from the data thread might race with a write from the
main thread and leave the bits in the wrong state.
This reverts commit 49cdb468c2.
We should not do this, the nsec field should be relatable to the clock
monotonic time. If we use the estimated time, without actually using it
as a timer, we might end up with a wakeup time in the future compared to
the MONOTONIC clock time.
Instead, you can use the estimated current time simply by subtracting
the rate corrected duration from the next_nsec. This is really only
useful for some selected use cases (like in the JACK library).
This fixes some issues where in pro-audio mode, a client would try to
compare the current MONOTONIC time to nsec and find that it is in the
past.
This commit was done in an attempt to fix#3657 but it turned out the
real problem was something else.
The alsa sequencer rate matching was not actually working correctly.
It would compare the previous queue time with the current time and
compare that to the quantum. This would include uncorrected errors from
jitter and would result in the timeouts being scaled in the wrong
direction forever.
Instead, calculate an ideal queue time and compare our current queue
time against that. We then use the correction to scale the timeout or
the next queue time prediction.
Also use the predicted time as the base time for the event timestamps.
this results in less jitter.
Fixes#3657
