- support loading modules dependent on wireplumber settings in JSON
config.
- load the settings module before parsing wireplumber.components,
so that dependencies can be fetched during parsing.
- access lua scripts are switched to JSON based config and lua configs
are removed.
- unlike pipewire, rules will be parsed during the bootup time, i.e
during the creation of the wpsettings object.
- The rules are parsed into the wpinterest objects and stored in the
wpsettings object, they will be eventually used to service the
apply_rule() API.
- Support pipewire syntax of rules defination in this version.
- settings.c tests conf file loading & parsing, metadata updates,
wpsetttings object creation and its API.
- settings.lua tests the API from lua scripts.
- Add a sample settings.conf file, this file contains sections copied
over from client.conf along with the settings section. Add a file
each for wp side and lua side of scripts.
- Make changes in base test infrastructure to take a custom conf file.
- Enhance the wp_settings_get_instance_api() to be take metadata_name
parameter. So, Wpsetttings is now a singleton instance for a given
metadata file.
- Enhance the m-settings module also to be take metadata_name parameter.
this is handy for lua side of tests as its cumbersome to do this is
lua.
- WpSettings is a singleton object which attaches itself to the core
and registry, it provides a get_instance () for its clients.
- WpSettings provides API to get/set wireplumber settings and rules.
- main.c loads the new object and makes sure it is available for
for all the modules and scripts. This is achieved by introducing
a new activation step.
- Add the lua bindings for get_setting API.
- parse settings from .conf file.
- create "sm-settings" metadata and copy settings as key value pairs
to it.
- put in place "persistent" behavior, control it with a special
setting.
- when persistent behavior is enabled.
- create a state file and update settings to it.
- monitor changes in the metadata and update the settings to state
file.
For Bluetooth LE Audio device sets (e.g. pair of earbuds), bluez5-device
emits "internal" nodes for each individual device, and a combine node
for the device set.
Make the bluetooth monitor to create the combine nodes using
module-combine-stream.
Do some shenanigans to route ObjectConfig events from bluez5-device to
the correct combine node: look for combine nodes associated with device
sets, and put them as managed objects of the Spa devices.
Add a new signal that gets emitted if any WpLink changes to an error
state. This allows better error handling in cases where e.g. no format
could be negotiated.
Add support for BLE MIDI devices and local endpoints.
Disabled by default for now, as the feature currently faces some
DBus/SELinux policy issues e.g. on Fedora.
The spa_json_encode_string() API does not add a null terminator character. We
need to use the return value to know the size of the encoded string when adding
it to the builder.
This is a tricky case where iteration matches the last 2 objects
managed by an object manager. When we remove them while iterating,
the last object is not removed because it takes the place of the first
upon removal (side-effect of g_ptr_array_remove_fast()) and the iterator
skips it.
See #388
For offload SCO, the audio stream should be routed to/from Bluetooth
chipset via ALSA.
To do this, this commit prevent the creation of the sco-source or sco-sink
nodes, and replace them by loopback nodes.
It's up to the platform to correctly the the route to the Bluetooth chipset
ALSA entries.
When the loopback node state change to running, the script also call the
bluetoothOffloadActive param of the device to start/stop the SCO link.
