Wp.SiLinkable¶

Implementations:: None

Methods¶

	`get_acquisition` ()
	`get_ports` (context)

Virtual Methods¶

	`do_get_acquisition` ()
	`do_get_ports` (context)

Properties¶

None

Signals¶

None

Fields¶

None

Class Details¶

class Wp.SiLinkable¶

Bases:: GObject.GInterface
Structure:: Wp.SiLinkableInterface

An interface for retrieving PipeWire port information from a session item. This information is used to create links in the nodes graph.

get_acquisition()¶

Returns:: the acquisition interface associated with this item, or None if this item does not require acquiring items before linking them
Return type:: Wp.SiAcquisition or None

Gets the acquisition interface associated with the item.

get_ports(context)¶

Parameters:: context (str or None) – an optional context for the ports
Returns:: a GLib.Variant containing information about the ports of this item
Return type:: GLib.Variant

This method returns a variant of type “a(uuu)”, where each tuple in the array contains the following information:

u: (guint32) node id
u: (guint32) port id (the port must belong on the node specified above)
u: (guint32) the audio channel (enum spa_audio_channel) that this port makes available, or 0 for non-audio content

The order in which ports appear in this array is important when no channel information is available. The link implementation should link the ports in the order they appear. This is normally a good enough substitute for channel matching. The context argument can be used to get different sets of ports from the item. The following well-known contexts are defined:

None: get the standard ports to be linked
“monitor”: get the monitor ports
“control”: get the control port
“reverse”: get the reverse direction ports, if this item controls a filter node, which would have ports on both directions

Contexts other than None may only be used internally to ease the implementation of more complex item relationships. For example, a Wp.SessionItem that is in control of an input (sink) adapter node may implement Wp.SiLinkable where the None context will return the standard input ports and the “monitor” context will return the adapter’s monitor ports. When linking this item to another item, the None context will always be used, but the item may internally spawn a secondary Wp.SessionItem that implements the “monitor” item. That secondary item may implement Wp.SiLinkable, chaining calls to the Wp.SiLinkable of the original item using the “monitor” context. This way, the monitor Wp.SessionItem does not need to share control of the underlying node; it only proxies calls to satisfy the API.

do_get_acquisition() virtual¶

Returns:: the acquisition interface associated with this item, or None if this item does not require acquiring items before linking them
Return type:: Wp.SiAcquisition or None

Gets the acquisition interface associated with the item.

do_get_ports(context) virtual¶

Parameters:: context (str or None) – an optional context for the ports
Returns:: a GLib.Variant containing information about the ports of this item
Return type:: GLib.Variant

This method returns a variant of type “a(uuu)”, where each tuple in the array contains the following information:

u: (guint32) node id
u: (guint32) port id (the port must belong on the node specified above)
u: (guint32) the audio channel (enum spa_audio_channel) that this port makes available, or 0 for non-audio content

The order in which ports appear in this array is important when no channel information is available. The link implementation should link the ports in the order they appear. This is normally a good enough substitute for channel matching. The context argument can be used to get different sets of ports from the item. The following well-known contexts are defined:

None: get the standard ports to be linked
“monitor”: get the monitor ports
“control”: get the control port
“reverse”: get the reverse direction ports, if this item controls a filter node, which would have ports on both directions

Contexts other than None may only be used internally to ease the implementation of more complex item relationships. For example, a Wp.SessionItem that is in control of an input (sink) adapter node may implement Wp.SiLinkable where the None context will return the standard input ports and the “monitor” context will return the adapter’s monitor ports. When linking this item to another item, the None context will always be used, but the item may internally spawn a secondary Wp.SessionItem that implements the “monitor” item. That secondary item may implement Wp.SiLinkable, chaining calls to the Wp.SiLinkable of the original item using the “monitor” context. This way, the monitor Wp.SessionItem does not need to share control of the underlying node; it only proxies calls to satisfy the API.