[][src]Module libpulse_binding::context::introspect

Routines for daemon introspection.

Overview

Sometimes it is necessary to query and modify global settings in the server. For this, PulseAudio has the introspection API. It can list sinks, sources, samples and other aspects of the server. It can also modify the attributes of the server that will affect operations on a global level, and not just the application’s context.

Usage

The introspection routines are exposed as methods on an Introspector object held by the Context object, and can be accessed via the Context object’s introspect method.

Querying

All querying is done through callbacks. This approach is necessary to maintain an asynchronous design. The client will request the information and some time later, the server will respond with the desired data.

Some objects can have multiple instances on the server. When requesting all of these at once, the callback will be called multiple times, each time with an ListResult variant. It will be called once for each item in turn, using the Item variant, and then once more time with the End variant to signal that the end of the list has been reached. If an error occurs, then the Error variant will be given.

Note that even if a single object is requested, and not the entire list, the terminating call will still be made.

Data members in the information structures are only valid during the duration of the callback. If they are required after the callback is finished, a deep copy of the information structure must be performed.

Server Information

The server can be queried about its name, the environment it’s running on and the currently active global defaults. Calling Introspector::get_server_info provides access to a ServerInfo structure containing all of these.

Memory Usage

Statistics about memory usage can be fetched using Introspector::stat, giving a StatInfo structure.

Sinks and Sources

The server can have an arbitrary number of sinks and sources. Each sink and source have both an index and a name associated with it. As such, there are three ways to get access to them:

All three methods use the same callback and will provide a SinkInfo or SourceInfo structure.

Sink Inputs and Source Outputs

Sink inputs and source outputs are the representations of the client ends of streams inside the server. I.e. they connect a client stream to one of the global sinks or sources.

Sink inputs and source outputs only have an index to identify them. As such, there are only two ways to get information about them:

The structure returned is the SinkInputInfo or SourceOutputInfo structure.

Samples

The list of cached samples can be retrieved from the server. Three methods exist for querying the sample cache list:

Note that this only retrieves information about the sample, not the sample data itself.

Driver Modules

PulseAudio driver modules are identified by index and are retrieved using either Introspector::get_module_info or Introspector::get_module_info_list. The information structure is called ModuleInfo.

Clients

PulseAudio clients are also identified by index and are retrieved using either Introspector::get_client_info or Introspector::get_client_info_list. The information structure is called ClientInfo.

Control

Some parts of the server are only possible to read, but most can also be modified in different ways. Note that these changes will affect all connected clients and not just the one issuing the request.

Sinks and Sources

The most common change one would want to apply to sinks and sources is to modify the volume of the audio. Identically to how sinks and sources can be queried, there are two ways of identifying them:

It is also possible to mute a sink or source:

Sink Inputs and Source Outputs

If an application desires to modify the volume of just a single stream (commonly one of its own streams), this can be done by setting the volume of its associated sink input or source output, using Introspector::set_sink_input_volume or Introspector::set_source_output_volume.

It is also possible to remove sink inputs and source outputs, terminating the streams associated with them:

It is strongly recommended that all volume changes are done as a direct result of user input. With automated requests, such as those resulting from misguided attempts of crossfading, PulseAudio can store the stream volume at an inappropriate moment and restore it later. Besides, such attempts lead to OSD popups in some desktop environments.

As a special case of the general rule above, it is recommended that your application leaves the task of saving and restoring the volume of its streams to PulseAudio and does not attempt to do it by itself. PulseAudio really knows better about events such as stream moving or headphone plugging that would make the volume stored by the application inapplicable to the new configuration.

Another important case where setting a sink input volume may be a bad idea is related to interpreters that interpret potentially untrusted scripts. PulseAudio relies on your application not making malicious requests (such as repeatedly setting the volume to 100%). Thus, script interpreters that represent a security boundary must sandbox volume-changing requests coming from their scripts. In the worst case, it may be necessary to apply the script-requested volume to the script-produced sounds by altering the samples in the script interpreter and not touching the sink or sink input volume as seen by PulseAudio.

If an application changes any volume, it should also listen to changes of the same volume originating from outside the application (e.g., from the system mixer application) and update its user interface accordingly. Use ::subscribe to get such notifications.

Modules

Server modules can be remotely loaded and unloaded using Introspector::load_module and Introspector::unload_module.

Clients

The only operation supported on clients is the possibility of kicking them off the server using Introspector::kill_client.

Structs

CardInfo

Stores information about cards.

CardPortInfo

Stores information about a specific port of a card.

CardProfileInfo2

Stores information about a specific profile of a card.

ClientInfo

Stores information about clients.

Introspector

A wrapper object providing introspection routines to a context.

ModuleInfo

Stores information about modules.

SampleInfo

Stores information about sample cache entries.

ServerInfo

Server information.

SinkInfo

Stores information about sinks.

SinkInputInfo

Stores information about sink inputs.

SinkPortInfo

Stores information about a specific port of a sink.

SourceInfo

Stores information about sources.

SourceOutputInfo

Stores information about source outputs.

SourcePortInfo

Stores information about a specific port of a source.

StatInfo

Memory block statistics.