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.
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)
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
The set_format function can return 1 when the format was adjusted to the
nearest supported format so return this from the port_set_param
function.
This instructs the adapter to recheck the configured format so that it
can store the adjuted format on the converter.
Airpods don't follow the specification and set multiple bits in AAC
object type, including the ELD bit, but actually want AAC-LC. So check
the AOT in the right order.
When setting Route param, check that the route actually is part of the
active profile.
Also, check that the device given corresponds to the given route, before
setting properties. acp_device_set_port() also checks this, but we
shouldn't allow updating properties of Routes in non-active profiles.
Setting ports or applying props on devices not part of the profile can
do unexpected things e.g. alter mixer settings.
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.
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
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.
