If the PCM is loaded directly using only api.alsa.path,
state->card_index may never be initialised, and then we end up opening
the wrong ctl device. Let's try a fallback for this case.
When we don't support EXPBUF according to the probe, the host will
allocate memory for us. We will then try to use USERPTR to import the
memory into v4l2.
If this is not supported, try to fall back to MMAP support, mmap the
buffers and memcpy the MMAP buffer to the host allocated buffers.
Instead of just probing with 2 buffers, probe with the MAX_BUFFERS and
remember how many buffers we received.
Some drivers (v4l2loopback) work with less than MAX_BUFFERS (8) and we
need to set the max number of buffers in the Buffers param.
When the driver node is destroyed (like when unplugging the cable) it
will drop/pause all of the follower ALSA nodes. This is something that
happens internally because of how the ALSA nodes work together, on the
PipeWire level, the nodes are still running and they will just be moved to
another driver.
The problem is that nothing will then start the nodes again after moving
it to the new driver. Fix this by keeping track of the desired target
state of the ALSA node and restoring that state when we detect that we are
paused when moved to a new driver.
Fixes#4401
Iterate the channels in the inner loop instead of the outer loop. This
makes it handle with 0 channels better but also does the more
complicated phase increment code only once for all channels. Also the
filters might stay in the cache for each channel now.
Similarly as in spa_dbus, don't exit if bus goes down. Neither the
audio or midi Bluetooth backend reconnects to DBus, but they shouldn't
exit the process.
Pick commits
doc: drop the links to configuration wiki pages
doc: rename pipewire-devices.7 and move stream properties into it
doc: document some more device properties
doc: move configuration index to a separate page
doc: document node/device disabled property
doc: add some small docs updates
docs: document negotiation of explicit sync
doc: remove duplicated entries, link to wireplumber docs
When the follower doesn't produce enough data for this many attempts,
bail and cause an xrun to avoid an infinite loop.
The limit of 8 cause real-life problems and should be larger. It should
probably depend on the expected size per cycle (node.latency) and the
current quantum but we don't always have this information.
See #4334
The properties of the card might overwrite those of the PCM.
For example, the cards's `alsa.id` will be set on the PCM too
since 37a51533e0 ("acp: add more properties for the card").
To avoid that, call `pa_alsa_init_proplist_card()` first
in `pa_alsa_init_proplist_pcm_info()` instead of last.
See #4135
The bar can start from 0 in JACK.
Add bar_start_tick and ticks_per_beat to the io_segment_bar so that we
can losslesly store the complete jack BBT values.
See #4314
non-systemd systems also have logind, in the form of elogind, which works to
resolve the v4l2 video source race just as well. permit finding elogind, by
using a separate dep object.
Some V4L2 controls like focus, pan or tilt can be relative (change
the lens / angle relative to previous positions) these return EACCES
when calling VIDIOC_G_CTRL on them.
Fix the v4l2 SPA not working on cameras with relative controls,
such as e.g. the Logitech QuickCam Orbit MP.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We have to unlink pcms when they are linked to a driver from
a different pcm.
When a playback and a capture pcm is linked and we start
the playback pcm and the capture pcm later this can leads
to a 'EPIPE' error on the capture device.
...
spa.alsa: hw:3,0c: snd_pcm_start: Broken pipe
...
When we drop the first buffer to avoid timestamp problems, queue it
again in the driver or else we will not be able to dequeue is again
later and we will be running with a buffer less.
There is a race between logind applying ACLs to allow the active session
of a locally present user access to devices with a udev uaccess tag
(like /dev/video# nodes) getting applied vs wireplumber/pipewire starting.
Wireplumber/pipewire are part of the (user) default.target, which gets
started as soon as a user logs in and systemd --user is started for that
user, where as logind only starts applying the ACLs after the gnome-shell
associated logind session has been created.
This race may cause pipewire to not see v4l2 video sources at login,
this can be reproduced with these steps:
1. sudo setfacl --remove-all /dev/video*
2. systemctl --user restart pipewire
3. Now wp-ctl status will not show any video devices
(like if pipewire was started before the udev uaccess ACLs got applied)
4. Do a switch to another (test) user without logging out, e.g. in GNOME
go to the top right system menu press the power on/off icon and select
"Switch User..."
5. Switch back to your normal user. Run getfacl /dev/video0 this will show
your user has access now.
6. wp-ctl status should show the camera now, but it does not.
Fix pipewire not seeing v4l2 sources in this case by making v4l2-udev
monitor systemd-logind session changes and redoing the access() checks
on /dev/video# nodes when the session changes.
Closes: #3539Closes: #3960
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 2a6ba61264)
The spa_loop_add_source() call for udev event monitoring which uses
impl_on_fd_events() is done from start_monitor() which also unconditionally
calls start_inotify().
Since start_monitor() already always calls start_inotify() there is no
scenario where start_inotify() has not been called yet when
impl_on_fd_events() gets called. So the start_inotify() call in
impl_on_fd_events() is redundant, remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit ab245947e5)
This reverts commit 9ae89b4247.
All invokes should be paired with a lock/unlock if the loop requires
this. For internal calls of invoke, this will also be true because all
pipewire functions should be called with the lock.
Fixes#4215
Claim that call waiting notifications are supported.
Required for some devices (e.g. Soundcore Motion 300),
as they stop sending commands if the reply to CCWA is not OK.
Now that start_monitor() (which calls start_inotify()) is called before
enum_devices() it no longer is necessary to call start_watching_device()
for devices which have been enumerated before start_inotify() gets
called (since there will not be any such devices anymore).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This fixes 2 races wrt probing v4l2 devices:
1. Before this change there was a window where a new udev device can get
added between the udev_enumerate_scan_devices() call in enum_devices() and
the udev_monitor_enable_receiving(this->umonitor); call. If this window was
hit then enum_devices() would not see the device and no udev-event for it
would be received either causing the device to not be seen.
Enabling udev event monitoring before calling udev_enumerate_scan_devices()
fixes this. Note that the code is already prepared to deal with getting
multiple add/change events for the same udev device, so hitting the new
race window where PipeWire may receive both an add- or change-event and
also sees + probes the device from enum_devices() is not a problem.
2. Before this change devices added by enum_devices() would not have
inotify monitoring activated right away because notify.fd = -1 at this
time turning start_watching_device() into a no-op.
These devices without inotify monitoring would then have their access
checked by process_device() calling check_access().
Then after all devices have been enumerated start_monitor() would call
start_inotify() which calls start_watching_device() for all devices added
by enum_devices(). This leaves a window where the ACL can change without
there being an inotify watch for it.
Calling start_monitor() before enum_devices() puts start_inotify()
notify before enum_devices() so that the add_device() calls done
by enum_devices() will now successfully call start_watching_device()
closing this window.
PipeWire is somewhat likely to not notify ACL changes because of this
because PipeWire is part of the systemd user default.target, where as
logind only starts applying the ACLs after GNOME has created the seat
for the GNOME session. So on first login we have PipeWire starting
and logind applying the ACLs at the same time, which allows for the ACL
change to hit the small race window where PipeWire is not monitoring
for ACL changes. Fixing this second race should hopefully resolve
issue #3960.
Closes: #3960
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some complex camera pipelines, like the IPU6 can involve many /dev/video#
nodes (32 in the IPU6 case) and the current size of 128 chars is not enough
to hold all /dev/video# nodes in this cases causing SPA_KEY_DEVICE_DEVIDS
to get truncated, which in turn breaks the filtering of V4L2 devices which
are used by a libcamera driven camera in wireplumber.
Fix this by increasing the size of devices_str[] to 256.
This fixes wireplumber adding a bunch of non-function V4L2 video sources,
e.g. before this "wpctl status" outputs the following video sources:
Video
├─ Devices:
...
├─ Sources:
│ 90. ov2740
│ * 115. ipu6 (V4L2)
...
│ 135. ipu6 (V4L2)
│
├─ Filters:
After this fix the output is:
Video
├─ Devices:
...
├─ Sources:
│ * 92. ov2740
│
├─ Filters:
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When the queue is full, before this patch we used to go into usleep in
the hope that the other thread will run and empty the queue and that we
can retry after the usleep.
This however does not always work because the other thread might be waiting
for the thread that does the invoke call and we lock forever.
Therefore we should always try to make progress in some way. Instead of
waiting, allocate an (or use the previously allocated) overflow queue and
write to that one. We can chain multiple overflow queues together as many
as we need (but we might want to bound that as well).
The loop.retry-timeout property is now deprecated.
See #4114
The control hooks of a loop are called before the loop starts polling
and after it has finished polling. Currently, this is used to implement
the locking in pw_thread_loop. This is used to guarantee that the thread
loop's lock is taken while the thread loop is dispatching, and that
the lock can be taken while the loop is polling, when it is running
no user-space code.
However, calling the thread control hooks of thread A when doing an
blocking invoke from thread B serves little purpose, and in fact
can cause issues: for example, issuing a blocking invoke on a
pw_thread_loop does not work unless the lock thereof is taken.
This behaviour, of calling the control hooks from other threads,
is also not documented, and goes contrary to what is currently
stated in the loop.h header file:
/** Executed right before waiting for events. It is typically used to
* release locks. */
...
/** Executed right after waiting for events. It is typically used to
* reacquire locks. */
At the moment the implementation allows any thread to queue invoke
items on any other thread without restrictions; calling the control
hooks only places extra restrictions on the usability of this mechanism
(in case of pw_thread_loop, having to take the loop's lock).
So do not call the control hooks when doing a blocking invoke.
While the spec allows for 1ppm changes, our rate matching logic applies
these changes quite often, which can be spammy on USB. I haven't seen
hosts mind this, but it seems like it might be a problem at some point.
Additionally, if we also have bind ctls enabled, every pitch update is
also a wakeup for ourselves (whether or not we're listening for the
pitch ctls, since the mixer fd does not distinguish between ctls, those
are filtered after we wake up).
The 10ppm threshold is empirically tested as being not "too noisy" (i.e.
when updates happen, I can see them scroll by with `amixer events`).
If necessary, we can make this configurable in the future.
The IO_Buffers is used in the data thread to check if the port should be
scheduled or not. Make sure it is only set after we set buffers on the
port and cleared before the buffers are cleared.
Make sure we sync the port->io with the data thread.
See #4094
Due to the how the kernel part of BlueZ computes the extended
advertising interval for a Broadcast Source, a sync_factor smaller
than 2 will result in an invalid interval value (too small).
