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.
Remove the monitor API, we can use the device API for it. Make sure
we support creating devices (like alsa) from another device (udev).
Use new object.id to store the object id in the object properties. Use
the port.id/node.id etc to make relations to other objects.
2019-09-20 13:04:14 +02:00
Renamed from spa/plugins/alsa/alsa-monitor.c (Browse further)
