wireplumber merge requestshttps://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests2024-03-29T07:43:28Zhttps://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/628Load SPA-JSON from disk2024-03-29T07:43:28ZJames CalligerosLoad SPA-JSON from diskThis MR implements loading a `WpSpaJson` object from a file on disk, and provides a constructor for the `Json` Lua class.
Depends on !627 for the final commit, can rebase atop `master` to remove that dependency if requiredThis MR implements loading a `WpSpaJson` object from a file on disk, and provides a constructor for the `Json` Lua class.
Depends on !627 for the final commit, can rebase atop `master` to remove that dependency if requiredhttps://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/627Port DSP policy to 0.52024-03-29T06:58:06ZJames CalligerosPort DSP policy to 0.5This is a first crack at porting the DSP handling stuff to the new configuration format, as well as adding some documentation.
Still on the todo list are porting the client ObjectManager to use Hooks, and implementing a nicer API to loa...This is a first crack at porting the DSP handling stuff to the new configuration format, as well as adding some documentation.
Still on the todo list are porting the client ObjectManager to use Hooks, and implementing a nicer API to load SPA-JSON from disk.
Addresses #619https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/535Enhance wireplumber configuration with 0.5 release changes.2023-12-23T10:41:25ZAshok SidipotuEnhance wireplumber configuration with 0.5 release changes.Enhance wireplumber configuration with 0.5 release changes.
Fixed the documentation errors in [528](https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/528/)
cc @julianEnhance wireplumber configuration with 0.5 release changes.
Fixed the documentation errors in [528](https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/528/)
cc @julianAshok SidipotuAshok Sidipotuhttps://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/520state-stream.lua: add restore-identifiers setting2023-10-25T18:28:15ZDuncan Overbruckstate-stream.lua: add restore-identifiers settingThis adds a new "stream.restore-identifiers" setting that allows to
reorder or change the properties used as identifiers to restore stream
properties.
This setting can also be set in the "stream.rules" to allow changing
"restore-identif...This adds a new "stream.restore-identifiers" setting that allows to
reorder or change the properties used as identifiers to restore stream
properties.
This setting can also be set in the "stream.rules" to allow changing
"restore-identifiers" for matching streams. Rules could as example
match streams with the "Music" role and prioritize "application.name"
and "application.id" properties over "media.role" without changing
the behaviour of other roles like "Notification" which would happen
if the global "stream.restore-identifiers" list is changed.https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/479Draft: 0.5: new permission system2023-04-11T12:31:50ZDmitry SharshakovDraft: 0.5: new permission systemGoal: grant permission in a fine-grained way, only allowing access when it's known to be needed.
Fixes #410Goal: grant permission in a fine-grained way, only allowing access when it's known to be needed.
Fixes #410https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/455Draft: Set media roles2023-04-12T09:23:29ZJonas Ã…dahlDraft: Set media rolesSets media roles to e.g. `Camera`, `Microphone`, `Speaker`. Draft as it needs to specify these roles somewhere.
It's also missing the Bluetooth bits.Sets media roles to e.g. `Camera`, `Microphone`, `Speaker`. Draft as it needs to specify these roles somewhere.
It's also missing the Bluetooth bits.https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/441Draft: [WIP] Resolve "PipeWire detection"2023-01-23T11:10:53ZAnthony IlersichDraft: [WIP] Resolve "PipeWire detection"Monitor scripts activate asynchronously when devices are found, and a new session.services property is populated as they do. This solution is based on the discussion in !313.
These changes depend on antonio.ilersich/pipewire:1835-sessio...Monitor scripts activate asynchronously when devices are found, and a new session.services property is populated as they do. This solution is based on the discussion in !313.
These changes depend on antonio.ilersich/pipewire:1835-session-detection, which adds the session.services property and blocks `pw_context_connect`. See pipewire!1409.https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/394tweak 50-alsa-config.lua VM values2023-11-14T19:49:30ZAdolfo Rodriguestweak 50-alsa-config.lua VM valuesDefault value made my vm have audio issues. This seams to fix itDefault value made my vm have audio issues. This seams to fix ithttps://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/313Draft: implement the session.initialized property2022-10-12T00:18:28ZPeter HuttererDraft: implement the session.initialized propertyThis is an attempt at addressing the race condition some applications
see at startup:
- pipewire is potentially socket-activated (or just about to start)
- application connects
- pipewire starts and starts pipewire-pulse and the session-...This is an attempt at addressing the race condition some applications
see at startup:
- pipewire is potentially socket-activated (or just about to start)
- application connects
- pipewire starts and starts pipewire-pulse and the session-manager
- application does things before the session manager is ready and fails
because none of the expected pieces are available.
The idea of addressing this race (partially) is to have a new property:
"session.initialized". This property is set to zero at startup of a
session manager, once the SM has completed its initialization period and
assumes it is "done", the property is set to the current timestamp.
The application can thus do two things:
- if there are no clients with "session.initialized", things may not
work as expected. It may be worth waiting...
- if there are clients with "session.initialized" of zero, things aren't
ready yet. It may be worth waiting...
- if all clients with "session.initialized" have it at nonzero, it's
worth querying the graph for information
Note that this still requires the applications to do most of the tricky
bit, the new property is merely there to make it easier to identify
whether it's a good idea to fail.
See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1553, cc @wtaymans
Notes:
- definitely a Draft, I have no idea whether wireplumber has (or can figure out) a state when it's "done for now"
- filing this here since the pipewire patch for this is merely a `PW_KEY_SESSION_INITIALIZED`