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
Previously both `impl_on_notify_events()` and `process_{device,card}()`
called `check_access()`. Avoid that by merging `ACTION_ADD` and
`ACTION_DISABLE` into a single `ACTION_CHANGE` and let `process_{device,card}()`
call `check_access()` and decide what to do.
Split up `process_{device,card}()` to have a separate function that does
the lookup based on the udev device, and only use that when there is
no available reference to the actual device/card object.
`IN_IGNORED` event is sent whenever the watch is removed,
which includes when the entity is deleted among other things,
so watch that instead of the more specific `IN_DELETE_SELF`.
When checking that a card has all of its PCM devices available, ignore
any specific device with the ACP_IGNORE udev environment variable. This
mirrors how we ignore whole cards, but specifically allows non-PipeWire
software to own specific PCM devices.
Note that this does not actually stop PipeWire from using those
subdevices right now, we assume UCM configs take care of that. This
should probably be implemented later to ensure PipeWire always stays
away from them, but for now this fixes the issue where it refuses to
probe the entire card.
Fixes: #3570
Signed-off-by: Hector Martin <marcan@marcan.st>
As part of this, in alsa-udev.c, certain structures and variables referred
to as "device" are renamed to "card". Otherwise, there is ambiguity, since
"device" can mean a udev device, an SPA device, a compress-offload device,
a PCM device etc.
Also, replace "card id" with "card number" to emphasize that these integers
are not actually SPA object IDs.
The order of attribute changes is random, so it's possible that controlCX is
accessible before the other devices, which marks the device as available but it
actually fails to open. Only consider the device accessible if both control and
PCM devices can be accessed.
This requires reacting to ATTRIB changes of pcm devices as well now.
Fixes#2534
If card busy check fails due to error, just log info message and
consider the card not busy.
For kernels with CONFIG_SND_PROCFS=n, /proc/asound is not present, and
we have to handle that. It's also better to fail open here, rather than
end up with missing devices.
For kernels compiled with CONFIG_SND_VERBOSE_PROCFS=n, the pcmXX
/proc/asound entries do not exist. In that case, the "device busy"
check cannot be done, but we should still check existence of PCM devices
correctly.
Count the number of PCM devices from /dev/snd, which should work also
without /proc/asound or /sysfs/class/sound.
Alsa device acp probe results to missing profiles if some PCM devices
are busy. Currently, we retry based on a timeout and give up after some
retries. However, exposing cards with missing profiles is never
useful.
Never expose cards if some PCM devices are busy. Instead, retry adding
device on inotify fd close events, which arrive when some process has
closed a PCM device.
When probing for devices in alsa-udev, check via /proc to avoid inotify
busy loop.
There is a race condition on udev permission changes (e.g. switching
VTs), when pipewire from one user closes devices, and the other process
from second user tries to open them. The close/open are not ordered, so
opening a device may fail in alsa-acp-device.c resulting to missing
devices/profiles.
Address this by trying to open devices already in alsa-udev.c. If some
devices are busy, do not emit the device info yet, but retry after a
timeout. If it still fails, go ahead emitting the device, even if some
profiles may be missing. The retry with delay should be enough to solve
the race almost always.
So that we can catch the SOUND_INITIALIZED update between enumerating
devices and starting the monitor.This fixes a races in detecting devices.
Thanks to Matthias Fend for finding this.
Fixes#2046
When we add a new listener to an object, it will emit the full state
of the object. For this it temporarily sets the change_mask to all
changes. Restore the previous state after this or else we might not
emit the right change_mask for the next listener.
Consider the case where one there are two listeners on an object.
The object emits a change and the first listener wants to enumerate the
changed params. For this is adds a new listener and then triggers the
enumeration. If we set the change_mask to 0 after adding the listener,
the second listener would get a 0 change_mask and fail to update
its state.
This replaces the manual check for "true" and some (inconsistent) return value
of atoi. All those instances now require either "true" or "1" to parse as
true, any other value (including NULL) is boolean false.
udev's ID_MODEL_ID and ID_VENDOR_ID are inconsistent: always 4-digit hex but
sound devices are prefixed with 0x, v4l devices are not. Depending on the
actual ID, the value will look like decimal (1234) or hex (a234).
pw-dump will then print those as either decimal integers (i.e. 0x1234 becomes
decimal 1234) or double (i.e. a234 becomes 41524.00).
Make this consistent by converting the string from hex do decimal where we
get it.
SPA_MEMBER is misleading, all we're doing here is pointer+offset and a
type-casting the result. Rename to SPA_PTROFF which is more expressive (and
has the same number of characters so we don't need to re-indent).
When the session becomes inactive (eg. user on active seat switched),
udev may make devices inaccessible. In this case, pipewire should give
up the devices and close their open file descriptors.
This is more in line with wayland and it allows us to create new
interfaces in modules without having to add anything to the type
enum. It also removes some lookups to map type_id to readable
name in debug.
