Currently pipewire-media-session uses ~/.pipewire-media-session for
storing configuration. Use home directory as specified by XDG base
directory specification viz. XDG_CONFIG_HOME and fall back to using
a default of $HOME/.config as per the spec if XDG_CONFIG_HOME is not
set or empty. Also in addition, all cases are now handled the same
and always end up using "%s/.config/pipewire-media-session".
If neither XDG_CONFIG_HOME or HOME are set, fall back to the earlier
approach.
Fixes: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/271
Signed-off-by: Sanchayan Maity <sanchayan@asymptotic.io>
Fixes!298
It is not clear if the port index is in the card or device port array
and it doesn't work when many ports are active. So simply iterate the
device ports and find the ones with the active flag set.
First move all completed operations to a new list, then complete
the operations and cancel the ones that are not completed correctly.
This ensures that new operations from the callbacks don't get
completed immediately as well.
The __x86_64__ macro identifies a CPU family, and is unfortunately not
enough to identify a concrete ABI.
The normal x86_64 ABI that is used by practical Linux distributions is
LP64 (i.e. 32-bit int, and 64-bit long and pointer), and defines
__x86_64__ and __LP64__.
x32 is a niche ILP32 ABI (i.e. 32-bit int, long and pointer) for x86_64
CPUs, which has different struct sizes due to sizeof(long) and
sizeof(void *) being smaller. It defines __x86_64__ and __ILP32__.
Signed-off-by: Simon McVittie <smcv@debian.org>
This is necessary on some 32-bit architectures that implement atomic
operations on 64-bit quantities as library calls, including Debian's
armel and mipsel ports.
Signed-off-by: Simon McVittie <smcv@debian.org>
Track the current route and the properties independently. Else we
might skip parsing the volumes/mute properties when the current
route didn't change.
Fixes#281
Use a global sync that both syncs the globals and completes the
operations.
In the case of a card profile change, first the nodes are removed
and added and then the Profile and Route info updated. We need to
be able to bind to the new node and get the device.profile.id
before we can find the active port of the node.
See #279
Continue processing the input data until we can't send anymore. When
we are following another driver, we need to process each buffer in
the cycle completely or we will start lagging behind.
