- Oct 22, 2020
-
-
Julian Bouzas authored
-
- Jun 29, 2020
-
-
George Kiagiadakis authored
1. device export proxies must be destroyed manually since they are not associated with the WpRegistry 2. the monitors should not disconnect before all WpSpaDevice objects are destroyed; remove the manual disconnect call and let GObject ref counting do its job (the core will disconnect when its last ref count is dropped after the last monitor plugin is destroyed)
-
George Kiagiadakis authored
JACK uses : as a separator to distinguish the port name from the node name, so it ends up doing wrong separations if we have : in the node name
-
- Jun 19, 2020
-
-
George Kiagiadakis authored
-
- Jun 15, 2020
-
-
George Kiagiadakis authored
We have multiple instances of the monitor plugin, but that's ok. connect/disonnect will not do anything bad if called multiple times We need to connect later so that the first connection is the one from main(). Otherwise, if there is a connection error, we will see the warning from the monitor first.
-
George Kiagiadakis authored
-
- Jun 12, 2020
-
-
Julian Bouzas authored
-
- Jun 11, 2020
-
-
Julian Bouzas authored
-
George Kiagiadakis authored
-
- Jun 10, 2020
-
-
George Kiagiadakis authored
-
George Kiagiadakis authored
By mistake, WpImplNode was developed by keeping in mind that the proxy returned by pw_core_export() is a PW_TYPE_INTERFACE_Node, but this is not true. It's actually a ClientNode... Unfortunately, making WpImplNode work as if it was a WpNode is not so easy, especially when it comes to handling params, which need to be queried syncrhonously on the underlying spa_node. So, instead of fixing WpImplNode to work as a WpNode, we choose to disconnect them. This way, WpImplNode will not be used as a proxy in the registry and the registry will normally create WpNode proxies instead, making round-trips through the server to change node params.
-
- Jun 02, 2020
-
-
George Kiagiadakis authored
-
- May 26, 2020
-
-
Julian Bouzas authored
-
Julian Bouzas authored
-
Julian Bouzas authored
-
Julian Bouzas authored
-
Julian Bouzas authored
-
Julian Bouzas authored
-
- May 25, 2020
-
-
Julian Bouzas authored
-
George Kiagiadakis authored
+ rename FEATURE_CONTROLS to FEATURE_PROPS + add accessor for the standard spa_param_info (info->params) + hide the low-level params API that nobody uses
-
- Apr 21, 2020
-
-
Julian Bouzas authored
-
- Mar 31, 2020
-
-
George Kiagiadakis authored
-
- Mar 20, 2020
-
-
Julian Bouzas authored
-
- Feb 11, 2020
-
-
George Kiagiadakis authored
* core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
-
- Jan 16, 2020
-
-
George Kiagiadakis authored
-
- Jan 13, 2020
-
-
Julian Bouzas authored
-
- Oct 14, 2019
-
-
George Kiagiadakis authored
The alsa.pcm devices currently use "device.api" = "alsa:pcm" but then the node overrides this later to just "alsa", which is confusing. For now, let's match "alsa:pcm" in the monitor, even though this does not appear on the node later. This commit fixes device preferences in wireplumber.conf, which were broken because the alsa endpoint names were empty of info about the alsa device
-
- Oct 07, 2019
-
-
George Kiagiadakis authored
-
- Sep 17, 2019
-
-
George Kiagiadakis authored
This is a generic WpMonitor loader that sets up the WpMonitor properties from the module arguments and applies some well-known properties to the device & node objects
-