Struct libpulse_binding::def::TimingInfo

#[repr(C)]
pub struct TimingInfo {
    pub timestamp: timeval,
    pub synchronized_clocks: i32,
    pub sink_usec: Usecs,
    pub source_usec: Usecs,
    pub transport_usec: Usecs,
    pub playing: i32,
    pub write_index_corrupt: i32,
    pub write_index: i64,
    pub read_index_corrupt: i32,
    pub read_index: i64,
    pub configured_sink_usec: Usecs,
    pub configured_source_usec: Usecs,
    pub since_underrun: i64,
}

A structure for all kinds of timing information of a stream.

See stream::Stream::update_timing_info and stream::Stream::get_timing_info.

The total output latency a sample that is written with stream::Stream::write takes to be played may be estimated by:

sink_usec + buffer_usec + transport_usec

(Where buffer_usec is defined as the result of passing write_index - read_index to sample::Spec::bytes_to_usec). The output buffer which buffer_usec relates to may be manipulated freely (with stream::Stream::write's seek argument, stream::Stream::flush and friends), the buffers sink_usec and source_usec relate to are first-in first-out (FIFO) buffers which cannot be flushed or manipulated in any way. The total input latency a sample that is recorded takes to be delivered to the application is:

source_usec + buffer_usec + transport_usec - sink_usec

(Take care of sign issues!). When connected to a monitor source sink_usec contains the latency of the owning sink. The two latency estimations described here are implemented in stream::Stream::get_latency.

All time values are in the sound card clock domain, unless noted otherwise. The sound card clock usually runs at a slightly different rate than the system clock.

Please note that this structure can be extended as part of evolutionary API updates at any time in any new release.

Fields

timestamp: timeval

The system clock time when this timing info structure was current.

synchronized_clocks: i32

Non-zero if the local and the remote machine have synchronized clocks. If synchronized clocks are detected transport_usec becomes much more reliable. However, the code that detects synchronized clocks is very limited and unreliable itself.

sink_usec: Usecs

Time in usecs a sample takes to be played on the sink. For playback streams and record streams connected to a monitor source.

source_usec: Usecs

Time in usecs a sample takes from being recorded to being delivered to the application. Only for record streams.

transport_usec: Usecs

Estimated time in usecs a sample takes to be transferred to/from the daemon. For both playback and record streams.

playing: i32

Non-zero when the stream is currently not underrun and data is being passed on to the device. Only for playback streams. This field does not say whether the data is actually already being played. To determine this check whether since_underrun (converted to usec) is larger than sink_usec.

write_index_corrupt: i32

Non-zero if write_index is not up-to-date because a local write command that corrupted it has been issued in the time since this latency info was current. Only write commands with stream::SeekMode::RelativeOnRead and stream::SeekMode::RelativeEnd can corrupt write_index.

write_index: i64

Current write index into the playback buffer in bytes.

Think twice before using this for seeking purposes: it might be out of date at the time you want to use it. Consider using stream::SeekMode::Relative instead.

read_index_corrupt: i32

Non-zero if read_index is not up-to-date because a local pause or flush request that corrupted it has been issued in the time since this latency info was current.

read_index: i64

Current read index into the playback buffer in bytes.

Think twice before using this for seeking purposes: it might be out of date at the time you want to use it. Consider using stream::SeekMode::RelativeOnRead instead.

configured_sink_usec: Usecs

The configured latency for the sink.

configured_source_usec: Usecs

The configured latency for the source.

since_underrun: i64

Bytes that were handed to the sink since the last underrun happened, or since playback started again after the last underrun. playing will tell you which case it is.

Trait Implementations