Lines Matching refs:the
3 - Trigger_tstamp is the system time snapshot taken when the .trigger
4 callback is invoked. This snapshot is taken by the ALSA core in the
7 estimate with a delay. In the latter two cases, the low-level driver
8 is responsible for updating the trigger_tstamp at the most appropriate
9 and precise moment. Applications should not rely solely on the first
10 trigger_tstamp but update their internal calculations if the driver
13 - tstamp is the current system timestamp updated during the last
15 The difference (tstamp - trigger_tstamp) defines the elapsed time.
18 and delay, which combined with the trigger and current system
19 timestamps allow for applications to keep track of the 'fullness' of
20 the ring buffer and the amount of queued samples.
23 the application needs:
25 - 'avail' reports how much can be written in the ring buffer
26 - 'delay' reports the time it will take to hear a new sample after all
29 When timestamps are enabled, the avail/delay information is reported
33 CLOCK_MONOTIC_RAW (without NTP corrections) and change the mode
37 The ALSA API also provide an audio_tstamp which reflects the passage
39 ascii-art, this could be represented as follows (for the playback
53 The analog time is taken at the last stage of the playback, as close
54 as possible to the actual transducer
56 The link time is taken at the output of the SOC/chipset as the samples
60 estimated (e.g. with the frame counter in USB).
62 The DMA time is measured using counters - typically the least reliable
63 of all measurements due to the bursty natured of DMA transfers.
65 The app time corresponds to the time tracked by an application after
66 writing in the ring buffer.
68 The application can query what the hardware supports, define which
69 audio time it wants reported by selecting the relevant settings in
70 audio_tstamp_config fields, get an estimate of the timestamp
71 accuracy. It can also request the delay-to-analog be included in the
72 measurement. Direct access to the link time is very interesting on
73 platforms that provide an embedded DSP; measuring directly the link
75 removes the need to keep track of internal DSP processing times and
78 In case the application requests an audio tstamp that is not supported
79 in hardware/low-level driver, the type is overridden as DEFAULT and the
80 timestamp will report the DMA time based on the hw_pointer value.
84 the results will default to the HDAudio wall clock for playback
85 streams and to the DMA time (hw_ptr) in all other cases.
90 - for dma time (default), the granularity of the transfers can be
91 inferred from the steps between updates and in turn provide
92 information on how much the application pointer can be rewound
95 - the link time can be used to track long-term drifts between audio
96 and system time using the (tstamp-trigger_tstamp)/audio_tstamp
97 ratio, the precision helps define how much smoothing/low-pass
99 or reported as is (the latter being useful to compare progress of
100 different streams - but may require the wallclock to be always
102 hardware, the absolute link time could also be used to define a
105 - including the delay in the audio timestamp may
106 counter-intuitively not increase the precision of timestamps, e.g. if a
108 hardware components the delay is typically not known with precision.
114 Due to the varied nature of timestamping needs, even for a single
115 application, the audio_tstamp_config can be changed dynamically. In
116 the STATUS ioctl, the parameters are read-only and do not allow for
123 at a time. This is a conscious design decision, reading the audio
124 timestamps from hardware registers or from IPC takes time, the more
125 timestamps are read the more imprecise the combined measurements
129 interpolation of the results
131 In some hardware-specific configuration, the system timestamp is
132 latched by a low-level audio subsytem, and the information provided
133 back to the driver. Due to potential delays in the communication with
134 the hardware, there is a risk of misalignment with the avail and delay
136 driver_timestamp field is added in the snd_pcm_status structure; this
137 timestamp shows when the information is put together by the driver
138 before returning from the STATUS and STATUS_EXT ioctl. in most cases
139 this driver_timestamp will be identical to the regular system tstamp.
169 Example 1 shows that the timestamp at the DMA level is close to 1ms
170 ahead of the actual playback time (as a side time this sort of
171 measurement can help define rewind safeguards). Compensating for the
172 DMA-link delay in example 2 helps remove the hardware buffering abut
173 the information is still very jittery, with up to one sample of
174 error. In example 3 where the timestamps are measured with the link
175 wallclock, the timestamps show a monotonic behavior and a lower
180 shows how compensating for the delay exposes a 1ms accuracy (due to
181 the use of the frame counter by the driver)