- Generated by
1.9.1
|
PulseAudio
16.0
|
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.
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, once for each object. When the list has been exhausted, the callback will be called without an information structure and the eol parameter set to a positive value.
Note that even if a single object is requested, and not the entire list, the terminating call will still be made.
If an error occurs, the callback will be invoked without an information structure and eol set to a negative value..
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.
The server can be queried about its name, the environment it's running on and the currently active global defaults. Calling pa_context_get_server_info() provides access to a pa_server_info structure containing all of these.
Statistics about memory usage can be fetched using pa_context_stat(), giving a pa_stat_info structure.
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 method use the same callback and will provide a pa_sink_info or pa_source_info structure.
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 pa_sink_input_info or pa_source_output_info structure.
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.
PulseAudio driver modules are identified by index and are retrieved using either pa_context_get_module_info() or pa_context_get_module_info_list(). The information structure is called pa_module_info.
PulseAudio clients are also identified by index and are retrieved using either pa_context_get_client_info() or pa_context_get_client_info_list(). The information structure is called pa_client_info.
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.
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:
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 pa_context_set_sink_input_volume() or pa_context_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 Event Subscription to get such notifications.
Server modules can be remotely loaded and unloaded using pa_context_load_module() and pa_context_unload_module().
Server objects like sinks, sink inputs or modules can register a message handler to communicate with clients. A message can be sent to a named message handler using pa_context_send_message_to_object().
The only operation supported on clients is the possibility of kicking them off the server using pa_context_kill_client().
1.9.1