@@ -1,4 +1,9 @@

 -------------------------------------------------------------------

+Mon Nov 27 08:46:54 UTC 2023 - Bjørn Lie <zaitor@opensuse.org>

+

+- Update to version 1.0.0

+

+-------------------------------------------------------------------

 Fri Nov 24 19:29:49 UTC 2023 - Bjørn Lie <zaitor@opensuse.org>

 - Update to version 0.3.85

​

@@ -7,7 +7,7 @@

 %define soversion 0_2

 Name:           pipewire-aptx

-Version:        0.3.85

+Version:        1.0.0

 Release:        0

 Summary:        PipeWire Bluetooth aptX codec plugin

 License:        MIT

​

@@ -1,123 +0,0 @@

-/**

-

-\defgroup api_pw_core Core API

-\brief PipeWire Core API

-\{

-\addtogroup pw_pipewire

-\addtogroup pw_main_loop

-\addtogroup pw_context

-\addtogroup pw_client

-\addtogroup pw_core

-\addtogroup pw_device

-\addtogroup pw_factory

-\addtogroup pw_link

-\addtogroup pw_loop

-\addtogroup pw_module

-\addtogroup pw_node

-\addtogroup pw_permission

-\addtogroup pw_port

-\addtogroup pw_proxy

-\addtogroup pw_registry

-\addtogroup pw_type

-\addtogroup pw_keys

-\}

-

-\defgroup api_pw_impl Implementation API

-\brief PipeWire Object Implementation API

-\{

-\addtogroup pw_impl_client

-\addtogroup pw_impl_core

-\addtogroup pw_impl_device

-\addtogroup pw_impl_factory

-\addtogroup pw_impl_link

-\addtogroup pw_impl_metadata

-\addtogroup pw_impl_module

-\addtogroup pw_impl_node

-\addtogroup pw_impl_port

-\addtogroup pw_buffers

-\addtogroup pw_control

-\addtogroup pw_data_loop

-\addtogroup pw_global

-\addtogroup pw_protocol

-\addtogroup pw_resource

-\addtogroup pw_thread_loop

-\addtogroup pw_work_queue

-\}

-

-\defgroup api_pw_util Utilities

-\brief PipeWire Utilities

-\{

-\addtogroup pw_array

-\addtogroup pw_conf

-\addtogroup pw_gettext

-\addtogroup pw_log

-\addtogroup pw_map

-\addtogroup pw_memblock

-\addtogroup pw_properties

-\addtogroup pw_thread

-\addtogroup pw_utils

-\}

-

-\defgroup api_pw_ext Extensions

-\brief PipeWire Extensions

-\{

-\addtogroup pw_client_node

-\addtogroup pw_metadata

-\addtogroup pw_profiler

-\addtogroup pw_protocol_native

-\addtogroup pw_session_manager

-\}

-

-\defgroup api_spa SPA

-\brief Simple Plugin API

-\{

-\addtogroup spa_buffer

-\addtogroup spa_control

-\addtogroup spa_debug

-\addtogroup spa_device

-\addtogroup spa_graph

-\addtogroup spa_node

-\addtogroup spa_param

-\addtogroup spa_pod

-\defgroup spa_utils Utilities

-Utility data structures, macros, etc.

-\{

-\addtogroup spa_ansi

-\addtogroup spa_utils_defs

-\addtogroup spa_dict

-\addtogroup spa_list

-\addtogroup spa_hooks

-\addtogroup spa_interfaces

-\addtogroup spa_json

-\addtogroup spa_json_pod

-\addtogroup spa_keys

-\addtogroup spa_names

-\addtogroup spa_result

-\addtogroup spa_ringbuffer

-\addtogroup spa_string

-\addtogroup spa_types

-\}

-\defgroup spa_support Support

-Support interfaces provided by host

-\{

-\addtogroup spa_cpu

-\addtogroup spa_dbus

-\addtogroup spa_i18n

-\addtogroup spa_log

-\addtogroup spa_loop

-\addtogroup spa_handle

-\addtogroup spa_plugin_loader

-\addtogroup spa_system

-\addtogroup spa_thread

-\}

-\}

-

-\defgroup pw_stream Stream

-\{

-\}

-

-\defgroup pw_filter Filter

-\{

-\}

-

-*/

​

@@ -1,89 +0,0 @@

-/** \page page_api PipeWire API

-

-The PipeWire API consists of several parts:

-

-- The \ref pw_stream for a convenient way to send and receive data streams from/to PipeWire.

-

-- The \ref pw_filter for a convenient way to implement processing filters.

-

-- The \ref api_pw_core to access a PipeWire instance. This API is used

-by all clients that need to communicate with the \ref page_daemon and provides

-the necessary structs to interface with the daemon.

-

-- The \ref api_pw_impl is primarily used by the \ref page_daemon itself but also by the

-\ref page_session_manager and modules/extensions that need to build objects in

-the graph.

-

-- The \ref api_pw_util containing various utility functions and structures.

-

-- The \ref api_pw_ext for interfacing with certain extension modules.

-

-The APIs work through proxy objects, so that calling a method on an object

-invokes that same method on the remote side. Marshalling and de-marshalling is

-handled transparently by the \ref page_module_protocol_native.

-The below graph illustrates this approach:

-

-\dot

-digraph API {

-  compound=true;

-  node shape="box";

-  rankdir="RL";

-

-  subgraph cluster_daemon {

-       rankdir="TB";

-       label="PipeWire daemon";

-       style="dashed";

-

-       impl_core label="Core Impl. Object";

-       impl_device label="Device Impl. Object";

-       impl_node label="Node Impl. Object";

-  }

-

-  subgraph cluster_client {

-       rankdir="TB";

-       label="PipeWire client";

-       style="dashed";

-

-       obj_core label="Core Object";

-       obj_device label="Device Object";

-       obj_node label="Node Object";

-  }

-

-  obj_core -> impl_core;

-  obj_device -> impl_device;

-  obj_node -> impl_node;

-

-}

-\enddot

-

-It is common for clients to use both the \ref api_pw_core and the \ref api_pw_impl

-and both APIs are provided by the same library.

-

-- \subpage page_client_impl

-- \subpage page_proxy

-- \subpage page_streams

-- \subpage page_thread_loop

-

-

-\addtogroup api_pw_core Core API

-

-The Core API to access a PipeWire instance. This API is used by all

-clients to communicate with the \ref page_daemon.

-

-If you are familiar with Wayland implementation, the Core API is

-roughly equivalent to libwayland-client.

-

-See: \ref page_api

-

-

-\addtogroup api_pw_impl Implementation API

-

-The implementation API provides the tools to build new objects and

-modules.

-

-If you are familiar with Wayland implementation, the Implementation API is

-roughly equivalent to libwayland-server.

-

-See: \ref page_api

-

-*/

​

@@ -1,55 +0,0 @@

-/** \mainpage PipeWire

-

-PipeWire is low-level multimedia framework that provides:

-

-- Graph based processing.

-- Support for out-of-process processing graphs with minimal overhead.

-- Flexible and extensible media format negotiation and buffer allocation.

-- Hard real-time capable plugins.

-- Very low-latency for both audio and video processing.

-

-See \ref page_overview for an overview of PipeWire and \ref page_design

-for the design principles guiding PipeWire.

-

-# Components

-

-PipeWire ships with the following components:

-

-- A \ref page_daemon that implements the IPC and graph processing.

-- An example \ref page_session_manager that manages objects in the \ref page_daemon.

-- A set of \ref page_tools to introspect and use the \ref page_daemon.

-- A \ref page_library to develop PipeWire applications and plugins (\ref

-  page_tutorial "tutorial").

-- The \ref page_spa used by both the \ref page_daemon and in the \ref

-  page_library.

-

-# API Documentation

-

-See \ref page_api.

-

-# More Documentation

-

-See our Wiki(https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home) for

-More information on how to configure and use PipeWire.

-

-# Resources

-

-- PipeWire and AGL(https://wiki.automotivelinux.org/_media/pipewire_agl_20181206.pdf)

-- LAC 2020 Paper(https://lac2020.sciencesconf.org/307881/document)

-- PipeWire Under The Hood(https://venam.nixers.net/blog/unix/2021/06/23/pipewire-under-the-hood.html)

-- PipeWire: The Linux audio/video bus (LWN)(https://lwn.net/Articles/847412)

-- PipeWire Wikipedia(https://en.wikipedia.org/wiki/PipeWire)

-- Bluetooth, PipeWire and Whatsapp calls(https://gjhenrique.com/pipewire.html)

-- Intoduction to PipeWire(https://bootlin.com/blog/an-introduction-to-pipewire/)

-- A custom PipeWire node(https://bootlin.com/blog/a-custom-pipewire-node/)

-

-

-\page page_overview

-\page page_pipewire

-\page page_tools

-\page page_pipewire_modules

-\page page_api

-\page page_spa

-\page page_tutorial

-

-*/

​

@@ -1,10 +0,0 @@

-#!/bin/bash

-#

-# Doxygen input filter that adds \privatesection to all files,

-# and removes macros.

-#

-# This is used for .c files, and causes Doxygen to not include

-# any symbols from them, unless they also appeared in a header file.

-#

-echo -n "/** \privatesection */ "

-sed -e 's/#define.*//' < "$1"

​

@@ -1,7 +0,0 @@

-/** \page @pagename@ @title@

-

-\brief Manual page for @title@

-

-\verbinclude @filename@

-

-*/

​

@@ -1,94 +0,0 @@

-/** \page page_pipewire_modules PipeWire Modules

-

-A PipeWire module is effectively a PipeWire client in an `.so` file that

-shares the \ref pw_context with the loading entity. Usually modules are

-loaded when they are listed in the configuration files. For example the

-default configuration file loads several modules:

-

-```

-context.modules = 

-    ...

-    # The native communication protocol.

-    {   name = libpipewire-module-protocol-native }

-

-    # The profile module. Allows application to access profiler

-    # and performance data. It provides an interface that is used

-    # by pw-top and pw-profiler.

-    {   name = libpipewire-module-profiler }

-

-    # Allows applications to create metadata objects. It creates

-    # a factory for Metadata objects.

-    {   name = libpipewire-module-metadata }

-

-    # Creates a factory for making devices that run in the

-    # context of the PipeWire server.

-    {   name = libpipewire-module-spa-device-factory }

-    ...

-

-```

-The matching libraries are:

-```

-$ ls -1 /usr/lib64/pipewire-0.3/libpipewire-module*

-...

-/usr/lib64/pipewire-0.3/libpipewire-module-metadata.so

-/usr/lib64/pipewire-0.3/libpipewire-module-profiler.so

-/usr/lib64/pipewire-0.3/libpipewire-module-protocol-native.so

-/usr/lib64/pipewire-0.3/libpipewire-module-spa-device-factory.so

-...

-```

-

-A module's entry point is the `pipewire__module_init` function, see \ref

-PIPEWIRE_SYMBOL_MODULE_INIT.

-

-\code

-int pipewire__module_init(struct pw_impl_module *module, const char *args).`

-\endcode

-

-See the \ref page_module_example_sink and \ref page_module_example_source

-modules for a general oveview of how modules look like.

-

-List of known modules:

-

-- \subpage page_module_access

-- \subpage page_module_adapter

-- \subpage page_module_avb

-- \subpage page_module_client_device

-- \subpage page_module_client_node

-- \subpage page_module_combine_stream

-- \subpage page_module_echo_cancel

-- \subpage page_module_example_filter

-- \subpage page_module_example_sink

-- \subpage page_module_example_source

-- \subpage page_module_fallback_sink

-- \subpage page_module_ffado_driver

-- \subpage page_module_filter_chain

-- \subpage page_module_jackdbus_detect

-- \subpage page_module_jack_tunnel

-- \subpage page_module_link_factory

-- \subpage page_module_loopback

-- \subpage page_module_metadata

-- \subpage page_module_netjack2_driver

-- \subpage page_module_netjack2_manager

-- \subpage page_module_pipe_tunnel

-- \subpage page_module_portal

-- \subpage page_module_profiler

-- \subpage page_module_protocol_native

-- \subpage page_module_protocol_pulse

-- \subpage page_module_protocol_simple

-- \subpage page_module_pulse_tunnel

-- \subpage page_module_raop_sink

-- \subpage page_module_raop_discover

-- \subpage page_module_roc_sink

-- \subpage page_module_roc_source

-- \subpage page_module_rtp_sap

-- \subpage page_module_rtp_sink

-- \subpage page_module_rtp_source

-- \subpage page_module_rtp_session

-- \subpage page_module_rt

-- \subpage page_module_session_manager

-- \subpage page_module_vban_recv

-- \subpage page_module_vban_send

-- \subpage page_module_x11_bell

-- \subpage page_module_zeroconf_discover

-

-*/

​

@@ -1,215 +0,0 @@

-/** \page page_portal Portal Access Control

-

-This document explains how clients from the portal are handled.

-

-The portal is a DBus service that exposes interfaces to

-request access to the PipeWire daemon to perform a certain set of

-functions. The PipeWire daemon runs outside the sandbox, the portal is a way

-for clients inside the sandbox to connect to and use PipeWire.

-

-The PipeWire socket is not exposed in the sandbox. Instead, The portal

-connects to PipeWire on behalf of the client, informing PipeWire that this

-client is a portal-managed client. PipeWire can detect and enforce

-extra permission checks on the portal managed clients.

-

-Once such portal is the camera

-portal(https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Camera)

-that provides a PipeWire session to stream video from a camera.

-

-

-# Use Cases

-

-## New Portal Managed Clients Need Device Permissions Configured

-

-When a new client is detected, the available objects need to be

-scanned and permissions configured for each of them.

-

-Only the devices belonging to the media_roles given by the

-portal are considered.

-

-## New Devices Need To Be Made Visible To Portal Managed Clients

-

-Newly created objects are made visible to a client when the client

-is allowed to interact with it.

-

-Only the devices belonging to the media_roles given by the

-portal are considered.

-

-## Permissions For A Device Need To Be Revoked

-

-The session manager listens to changes in the permissions of devices

-and will remove the client permissions accordingly.

-

-Usually this is implemented by listening to the permission store

-DBus object. The desktop environment might provide a configuration panel

-where these permissions can be managed.

-

-

-# Design

-

-## The Portal

-

-A sandboxed client cannot connect to PipeWire directly. Instead, it connects

-to the sandbox side of the portal which then connects the PipeWire daemon to

-configure the session. The portal then hands the file descriptor of the

-PipeWire connection to the client and the client can use this file descriptor

-to interface with the PipeWire session directly.

-

-When the portal connects, it will set the following properties on the

-client object:

-

-- `"pipewire.access.portal.is_portal" = true` for the connection of the

-  portal itself (as opposed to a client managed by the portal).

-- `"pipewire.access.portal.app_id"` the application ID(https://docs.flatpak.org/en/latest/conventions.html#application-ids) of the client.

-- `"pipewire.access.portal.media_roles"` media roles of the client.

-  Currently only `"Camera"` is defined.

-

-Before returning the connection to a client, the portal configures

-minimal permissions on the client. No objects are initially visible. It is

-the task of the \ref page_session_manager to make the objects in the graph

-visible, depending on the client's `media_roles` (see also \ref

-PW_KEY_MEDIA_ROLE).

-

-## The PipeWire Portal Module

-

-The PipeWire daemon uses the \ref page_module_portal to find the PID of the

-processes that owns the DBus name `org.freedesktop.portal.Desktop`

-(see the XDG Desktop Portal(https://github.com/flatpak/xdg-desktop-portal)).

-

-Client connections from this PID are tagged as \ref PW_KEY_ACCESS

-`"portal"` (see \ref page_module_access). It will also set ALL permissions for

-this client so that it can resume.

-

-\dot

-digraph pw {

-  compound=true;

-  node shape="box";

-  rankdir="TB";

-

-  dbus label="org.freedesktop.portal.Desktop";

-

-  portal_access label="PipeWire (mod: Portal Access)";

-  portal label="xdg-desktop-portal";

-

-  dbus -> portal_access arrowhead="dot";

-  dbus -> portal arrowhead="dot";

-

-  portal_access -> portal label="pipewire.access = portal";

-

-  { rank="same"; portal_access; portal}

-}

-\enddot

-

-## The Client

-

-A client can ask the portal for a connection to the PipeWire daemon.

-

-\dot

-digraph pw {

-  compound=true;

-  node shape="box";

-  rankdir="LR";

-

-  pw label="PipeWire";

-  portal label="xdg-desktop-portal";

-  client label="client";

-

-  client -> portal;

-  portal -> pw label="portal.is_portal=true", arrowhead="none"

-

-  {rank="min"; pw};

-  {rank="max"; client};

-}

-\enddot

-

-The portal maintains an (unrestricted) connection to the PipeWire daemon with

-`"pipewire.access.portal.is_portal" = true` to identify the nodes the client

-needs access to. It then creates a new restricted connection for the client,

-tagged with additional information.

-

-\dot

-digraph pw {

-  compound=true;

-  node shape="box";

-  rankdir="LR";

-

-  pw label="PipeWire";

-  portal label="xdg-desktop-portal";

-  client label="client";

-

-  client -> portal arrowhead="none";

-  portal -> pw label="portal.is_portal=true", arrowhead="none"

-  portal -> pw label="portal.app_id = $appid"

-

-  {rank="min"; pw};

-  {rank="max"; client};

-}

-\enddot

-

-The file descriptor for this restricted connection is passed back to the

-client which can now make use of the resources it has been permitted to

-access.

-

-\dot

-digraph pw {

-  compound=true;

-  node shape="box";

-  rankdir="LR";

-

-  pw label="PipeWire";

-  portal label="xdg-desktop-portal";

-  client label="client";

-

-  portal -> pw label="portal.is_portal=true", arrowhead="none"

-

-  pw->client label="restricted connection";

-

-  {rank="min"; pw};

-  {rank="max"; client};

-}

-\enddot

-

-## The Session Manager

-

-The session manager listens for new clients to appear. It will use the

-\ref PW_KEY_ACCESS property to find portal connections. For client connections

-from the portal the session manager checks the requested `media_roles` and

-enables or disables access to the respective PipeWire objects.

-It might have to consult a database to decide what is allowed, for example the

-org.freedesktop.impl.portal.PermissionStore(https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.PermissionStore).

-

-\dot

-strict digraph pw {

-  compound=true;

-  node shape="box";

-  rankdir="LR";

-

-  portal label="xdg-desktop-portal";

-  client label="client";

-

-

-  subgraph {

-     rankdir="TB";

-     permissions label="PermissionStore";

-

-     sm->permissions;

-

-     sm label="Session Manager";

-     pw label="PipeWire";

-     sm -> pw headlabel="allow $media.roles";

​

@@ -1,1573 +0,0 @@

-/** \page page_native_protocol Native Protocol

-

-PipeWire has a pluggable client/server IPC protocol.

-

-The reference implementation uses unix sockets and is implemented in

-\ref page_module_protocol_native.

-

-We document the messages here.

-

-# Message header

-

-Each message on the unix socket contains a 16 bytes header and a

-variable length payload size:

-

-```

-    0                   1                   2                   3

-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                     Id                                        |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |    opcode     |                   size                        |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                         seq                                   |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                         n_fds                                 |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                     payload POD                               |

-   .                                                               .

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                     optional footer POD                       |

-   .                                                               .

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-```

-

-

-These are four uint32 words to be read in native endianness.

-

-- Id: the message id this is the destination resource/proxy id

-- opcode: the opcode on the resource/proxy interface

-- size: the size of the payload and optional footer of the message

-- seq: an increasing sequence number for each message

-- n_fds: number of file descriptors in this message.

-

-The sender should send along with each message the fds that belong to

-the message. If there are more than the maximum number of fds in the

-message than can fit in one message, the message is split into multiple

-parts.

-

-A receiver needs to first read the header to know the size of the

-complete message. After collecting the complete message, it can start

-processing it.

-

-The payload is a single POD see \ref page_spa_pod for details.

-

-After the payload, there is an optional footer POD object.

-

-# Making a connection

-

-First a connection is made to a unix domain socket. By default, the socket is

-named as "pipewire-0" and searched in the following directories:

-

- - getenv("PIPEWIRE_RUNTIME_DIR")

- - getenv("XDG_RUNTIME_DIR")

- - getenv("USERPROFILE")

-

-

-The client opens the socket and allocates a Core proxy with id 0 and a Client

-proxy with id 1. The proxy is nothing more than a way to identify the remote

-objects with an id. Usually they also contain the type and version of the

-remote object and some helpers (interfaces) to dispatch messages.

-

-The server will allocate a new Core resource with id 0. Resources are the

-counterpart of client proxies and also typically contain extra information

-and helpers (interfaces) to dispatch messages.

-

-The client sends the Core::Hello message on the socket to start the

-communication.

-

-The server binds the client resource with id 1 to the client. This means

-that the client object on the server will now have a resource with a

-client side proxy associated with it.

-

-When the client sends a message for a certain proxy, the server side

-resource with the same id for the client is found and the message is

-dispatched to the object associated with the resource.

-

-Similarly when a server sends a message on a resource, the client will

-find the proxy with the same id and dispatch the message to it's

-associated object.

-

-The client then sends client properties to the server.

-

-```

-   client                                    server

-     |---------------------------------------->|

-     |            open socket                  |

-     |                                         |

-     |---------------------------------------->|

-     |            Core::Hello(version)         |

-     |                                         |

-     |---------------------------------------->|

-     |       Client::UpdateProperties          |

-     .                                         .

-```

-

-This completes the setup of the client. The newly connected client will

-appear in the registry at this point.

-

-# Core proxy/resource

-

-The core is always the object with Id 0.

-

-## Core Methods (Id 0)

-

-### Core::Hello (Opcode 1)

-

-The first message sent by a client is the Hello message and contains the

-version number of the client.

-

-```

-   Struct(

-      Int: version

-   )

-```

-

-The version is 3.

-

-### Core::Sync (Opcode 2)

-

-The Sync message will result in a Done event from the server. When the Done

-event is received, the client can be sure that all operations before the Sync

-method have been completed.

-

-```

-   Struct(

-      Int: id

-      Int: seq

-   )

-```

-

-- id: the id will be returned in the Done event.

-- seq: is usually generated automatically and will be returned in the Done event.

-

-### Core::Pong (Opcode 3)

-

-Is sent from the client to the server when the server emits the Ping event.

-The id and seq should be copied from the Ping event.

-

-```

-   Struct(

-      Int: id

-      Int: seq

-   )

-```

-

-### Core::Error (Opcode 4)

-

-An error occured in an object on the client.

-

-```

-   Struct(

-      Int: id

-      Int: seq

-      Int: res

-      String: message

-   )

-```

-

-- id: The id of the proxy that is in error.

-- seq: a seq number from the failing request (if any)

-- res: a negative errno style error code

-- message: an error message

-

-### Core::GetRegistry (Opcode 5)

-

-A client requests to bind to the registry object and list the available objects

-on the server.

-

-Like with all bindings, first the client allocates a new proxy id and puts this

-as the new_id field. Methods and Events can then be sent and received on the 

-new_id (in the message Id field).

-

-```

-   Struct(

-      Int: version

-      Int: new_id

-   )

-```

-- version: the version of the registry interface used on the client

-- new_id: the id of the new proxy with the registry interface

-

-After this method, the server will start sending Registry::Global events

-to the proxy with new_id.

-

-```

-   client                                    server

-     |                                         |

-     | new proxy(new_id)                       |

-     |---------------------------------------->|  new resource(new_id)

​

@@ -1,193 +0,0 @@

-/** \page page_scheduling Graph Scheduling

-

-This document tries to explain how the PipeWire graph is scheduled.

-

-Graph are constructed from linked nodes together with their ports. This

-results in a dependency graph between nodes. Special care is taken for

-loopback links so that the graph remains a directed graph.

-

-

-# Nodes

-

-Nodes are objects with 0 or more input and output ports.

-

-Each node also has:

-

-- an eventfd to signal the node that it can start processing

-- an activation record that lives in shared memory with memfd.

-

-```

-   eventfd

-  +-^---------+

-  |           |

- in          out

-  |           |

-  +-v---------+

-    activation {

-      status:OK,        // bitmask of NEED_DATA, HAVE_DATA or OK

-      pending:0,   // number of unsatisfied dependencies to be able to run

-      required:0        // number of dependencies with other nodes

-    }

-```

-

-The activation record has the following information:

-

- - processing state and pending dependencies. As long as there are pending dependencies

-   the node can not be processed. This is the only relevant information for actually

-   scheduling the graph and is shown in the above illustration.

- - Current status of the node and profiling info (TRIGGERED, AWAKE, FINISHED, timestamps

-   when the node changed state).

- - Timing information, mostly for drivers when the processing started, the time, duration

-   and rate (quantum) etc..

- - Information about repositions (seek) and timebase owners.

-

-

-# Links

-

-When two nodes are linked together, the output node becomes a dependency for the input

-node. This means the input node can only start processing when the output node is finished.

-

-This dependency is reflected in the required counter in the activation record. In below

-illustration, B's required field is incremented with 1. The pending field is set to the

-required field when the graph is started. Node A will keep a list of all targets (B) that it

-is a dependency of.

-

-This dependency update is only performed when the link is ready (negotiated) and the nodes

-are ready to schedule (runnable).

-

-

-```

-   eventfd                                eventfd

-  +-^---------+                          +-^---------+

-  |           |        link              |           |

- in     A    out ---------------------> in     B    out

-  |           |                          |           |

-  +-v---------+                          +-v---------+

-    activation {       target              activation {

-      status:OK,  -------------------->      status:OK,

-      pending:0,                             pending:1,

-      required:0                             required:1

-    }                                      }

-```

-

-Multiple links between A and B will only result in 1 target link between A and B.

-

-

-# Drivers

-

-The graph can only run if there is a driver node that is in some way linked to an

-active node.

-

-The driver is special because it will have to initiate the processing in the graph. It

-will use a timer or some sort of interrupt from hardware to start the cycle.

-

-Any node can also be a candidate for a driver (when the node.driver property is true).

-PipeWire will select the node with the highest priority.driver property as the driver.

-

-Nodes will be assigned to the driver node they will be scheduled with. Each node holds

-a reference to the driver and increments the required field of the driver.

-

-When a node is ready to be scheduled, the driver adds the node to its list of targets

-and increments the required field.

-

-

-```

-   eventfd                                eventfd

-  +-^---------+                          +-^---------+

-  |           |        link              |           |

- in     A    out ---------------------> in     B    out

-  |           |                          |           |

-  +-v---------+                          +-v---------+

-    activation {       target              activation {

-      status:OK,  -------------------->      status:OK,

-      pending:0,                             pending:0,

-      required:1                             required:2

-    }                                      }

-      |    ^                         ^

-      |    |                        /   /

-      |    |                       /   /

-      |    |                      /   /

-      |    |                     /   /

-      |    |                    /   /

-      v    |     /-------------/   /

-    activation {                  /

-      status:OK, V---------------/

-      pending:0,

-      required:2

-    }

-  +-^---------+

-  |           |

-  |   driver  |

-  |           |

-  +-v---------+

-   eventfd

-```

-

-As seen in the illustration above, the driver holds a link to each node it needs to

-schedule and each node holds a link to the driver. Some nodes hold a link to other

-nodes.

-

-It is possible that the driver is the same as a node in the graph (for example node A)

-but conceptually, the links above are still valid.

-

-The driver will then start processing the graph by emitting the ready signal. PipeWire

-will then:

-

- - Check the previous cycle. Did it complete? Mark xrun on unfinished nodes.

- - Perform reposition requests if any, timebase changes, etc..

- - The pending counter of each follower node is set to the required field.

- - It then loops over all targets of the driver and atomically decrements the required

-   field of the activation record. When the required field is 0, the eventfd is signaled

-   and the node can be scheduled.

-

-In our example above, Node A and B will have their pending state decremented. Node A

-will be 0 and will be triggered first (node B has 2 pending dependencies to start with and

-will not be triggered yet). The driver itself also has 2 dependencies left and will not

-be triggered (complete) yet.

-

-## Scheduling node A

-

-When the eventfd is signaled on a node, we say the node is triggered and it will be able

-to process data. It consumes the input on the input ports and produces more data on the

-output ports.

-

-After processing, node A goes through the list of targets and decrements each pending

-field (node A has a reference to B and the driver).

-

-In our above example, the driver is decremented (from 2 to 1) but is not yet triggered.

-node B is decremented (from 1 to 0) and is triggered by writing to the eventfd.

-

-## Scheduling node B

-

-Node B is scheduled and processes the input from node A. It then goes through the list of

-targets and decrements the pending fields.  It decrements the pending field of the

-driver (from 1 to 0) and triggers the driver.

-

-## Scheduling the driver

-

-The graph always completes after the driver is triggered and scheduled. All required

-fields from all the nodes in the target list of the driver are now 0.

-

-The driver calculates some stats about cpu time etc.

-

-# Remote nodes.

-

-For remote nodes, the eventfd and the activation is transfered from the server

-to the client.

-

-This means that writing to the remote client eventfd will wake the client directly

-without going to the server first.

-

-All remote clients also get the activation and eventfd of the peer and driver they

-are linked to and can directly trigger peers and drivers without going to the

-server first.

-

-## Remote driver nodes.

-

-Remote drivers start the graph cycle directly without going to the server first.

-

-After they complete (and only when the profiler is active), they will trigger an

-extra eventfd to signal the server that the graph completed. This is used by the

-server to generate the profiler info.

-

-*/

​

@@ -1,7 +0,0 @@

-/** \page page_tools PipeWire Tools

-

-Manual pages:

-

-@man_subpages@

-

-*/

​

@@ -1,26 +0,0 @@

-/** \page page_pipewire PipeWire Design

-

-# Internals

-

-- \subpage page_design

-- \subpage page_audio

-- \subpage page_access

-- \subpage page_portal

-- \subpage page_midi

-- \subpage page_objects_design

-- \subpage page_library

-- \subpage page_dma_buf

-- \subpage page_scheduling

-- \subpage page_native_protocol

-

-

-# Components

-

-- \subpage page_daemon

-- \subpage page_session_manager

-

-# Backends

-

-- \subpage page_pulseaudio

-

-*/

​

@@ -1,21 +0,0 @@

-/** \page page_tutorial Tutorial

-

-Welcome to the PipeWire tutorial. The goal is to learn

-PipeWire API step-by-step with simple short examples.

-

-- \subpage page_tutorial1

-- \subpage page_tutorial2

-- \subpage page_tutorial3

-- \subpage page_tutorial4

-- \subpage page_tutorial5

-- \subpage page_tutorial6

-

-

-# More Example Programs

-

-- \ref audio-src.c "": \snippet{doc} audio-src.c title

-- \ref audio-dsp-filter.c "": \snippet{doc} audio-dsp-filter.c title

-- \ref video-play.c "": \snippet{doc} video-play.c title

-- \subpage page_examples

-

-*/

​

-(directory)

​

@@ -1,45 +0,0 @@

-manpage_conf = configuration_data()

-manpage_conf.set('PACKAGE_NAME', meson.project_name())

-manpage_conf.set('PACKAGE_VERSION', meson.project_version())

-manpage_conf.set('PACKAGE_URL', 'https://pipewire.org')

-manpage_conf.set('PACKAGE_BUGREPORT', 'https://gitlab.freedesktop.org/pipewire/pipewire/issues')

-manpage_conf.set('PIPEWIRE_CONFIG_DIR', pipewire_configdir)

-manpage_conf.set('PIPEWIRE_CONFDATADIR', pipewire_confdatadir)

-

-manpages = 

-  'pipewire.1.rst.in',

-  'pipewire-pulse.1.rst.in',

-  'pipewire.conf.5.rst.in',

-  'pw-cat.1.rst.in',

-  'pw-cli.1.rst.in',

-  'pw-config.1.rst.in',

-  'pw-dot.1.rst.in',

-  'pw-link.1.rst.in',

-  'pw-metadata.1.rst.in',

-  'pw-mididump.1.rst.in',

-  'pw-mon.1.rst.in',

-  'pw-profiler.1.rst.in',

-  'pw-top.1.rst.in',

-

-

-if get_option('pipewire-jack').allowed()

-  manpages += 'pw-jack.1.rst.in'

-endif

-

-if not generate_manpages

-  subdir_done()

-endif

-

-foreach m : manpages

-  file = m.split('.rst.in').get(0)

-  rst = configure_file(input : m,

-                       output : file + '.rst',

-                       configuration : manpage_conf)

-  section = file.split('.').get(-1)

-  custom_target(file + '.target',

-                output : file,

-                input : rst,

-                command : rst2man, '@INPUT@', '@OUTPUT@',

-                install : true,

-                install_dir : get_option('mandir') / 'man' + section)

-endforeach

​

@@ -1,48 +0,0 @@

-pipewire-pulse

-##############

-

------------------------------------

-The PipeWire PulseAudio replacement

------------------------------------

-

-:Manual section: 1

-:Manual group: General Commands Manual

-

-SYNOPSIS

-========

-

-| **pipewire-pulse** *options*

-

-DESCRIPTION

-===========

-

-**pipewire-pulse** starts a PulseAudio-compatible daemon that integrates with

-the PipeWire media server, by running a pipewire process through a systemd

-service. This daemon is a drop-in replacement for the PulseAudio daemon.

-

-OPTIONS

-=======

-

--h | --help

-  Show help.

-

--v | --verbose

-  Increase the verbosity by one level. This option may be specified multiple

-  times.

-

---version

-  Show version information.

-

--c | --config=FILE

-  Load the given config file (Default: pipewire-pulse.conf).

-

-AUTHORS

-=======

-

-The PipeWire Developers <@PACKAGE_BUGREPORT@>;

-PipeWire is available from @PACKAGE_URL@

-

-SEE ALSO

-========

-

-``pipewire(1)``

​

@@ -1,54 +0,0 @@

-pipewire

-########

-

--------------------------

-The PipeWire media server

--------------------------

-

-:Manual section: 1

-:Manual group: General Commands Manual

-

-SYNOPSIS

-========

-

-| **pipewire** *options*

-

-DESCRIPTION

-===========

-

-PipeWire is a service that facilitates sharing of multimedia content

-between devices and applications.

-

-The **pipewire** daemon reads a config file that is further documented in

-``pipewire.conf(5)`` manual page.

-

-OPTIONS

-=======