^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) ALSA PCM Timestamping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) The ALSA API can provide two different system timestamps:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) - Trigger_tstamp is the system time snapshot taken when the .trigger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) callback is invoked. This snapshot is taken by the ALSA core in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) general case, but specific hardware may have synchronization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) capabilities or conversely may only be able to provide a correct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) estimate with a delay. In the latter two cases, the low-level driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) is responsible for updating the trigger_tstamp at the most appropriate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) and precise moment. Applications should not rely solely on the first
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) trigger_tstamp but update their internal calculations if the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) provides a refined estimate with a delay.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) - tstamp is the current system timestamp updated during the last
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) event or application query.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) The difference (tstamp - trigger_tstamp) defines the elapsed time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) The ALSA API provides two basic pieces of information, avail
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) and delay, which combined with the trigger and current system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) timestamps allow for applications to keep track of the 'fullness' of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) the ring buffer and the amount of queued samples.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) The use of these different pointers and time information depends on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) the application needs:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) - ``avail`` reports how much can be written in the ring buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) - ``delay`` reports the time it will take to hear a new sample after all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) queued samples have been played out.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) When timestamps are enabled, the avail/delay information is reported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) along with a snapshot of system time. Applications can select from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) ``CLOCK_REALTIME`` (NTP corrections including going backwards),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) ``CLOCK_MONOTONIC`` (NTP corrections but never going backwards),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) ``CLOCK_MONOTIC_RAW`` (without NTP corrections) and change the mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) dynamically with sw_params
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) The ALSA API also provide an audio_tstamp which reflects the passage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) of time as measured by different components of audio hardware. In
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) ascii-art, this could be represented as follows (for the playback
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) case):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) --------------------------------------------------------------> time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) ^ ^ ^ ^ ^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) | | | | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) analog link dma app FullBuffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) time time time time time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) | | | | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) |< codec delay >|<--hw delay-->|<queued samples>|<---avail->|
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) |<----------------- delay---------------------->| |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) |<----ring buffer length---->|
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) The analog time is taken at the last stage of the playback, as close
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) as possible to the actual transducer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) The link time is taken at the output of the SoC/chipset as the samples
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) are pushed on a link. The link time can be directly measured if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) supported in hardware by sample counters or wallclocks (e.g. with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) HDAudio 24MHz or PTP clock for networked solutions) or indirectly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) estimated (e.g. with the frame counter in USB).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) The DMA time is measured using counters - typically the least reliable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) of all measurements due to the bursty nature of DMA transfers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) The app time corresponds to the time tracked by an application after
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) writing in the ring buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) The application can query the hardware capabilities, define which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) audio time it wants reported by selecting the relevant settings in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) audio_tstamp_config fields, thus get an estimate of the timestamp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) accuracy. It can also request the delay-to-analog be included in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) measurement. Direct access to the link time is very interesting on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) platforms that provide an embedded DSP; measuring directly the link
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) time with dedicated hardware, possibly synchronized with system time,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) removes the need to keep track of internal DSP processing times and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) latency.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) In case the application requests an audio tstamp that is not supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) in hardware/low-level driver, the type is overridden as DEFAULT and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) timestamp will report the DMA time based on the hw_pointer value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) For backwards compatibility with previous implementations that did not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) provide timestamp selection, with a zero-valued COMPAT timestamp type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) the results will default to the HDAudio wall clock for playback
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) streams and to the DMA time (hw_ptr) in all other cases.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) The audio timestamp accuracy can be returned to user-space, so that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) appropriate decisions are made:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) - for dma time (default), the granularity of the transfers can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) inferred from the steps between updates and in turn provide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) information on how much the application pointer can be rewound
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) safely.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) - the link time can be used to track long-term drifts between audio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) and system time using the (tstamp-trigger_tstamp)/audio_tstamp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) ratio, the precision helps define how much smoothing/low-pass
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) filtering is required. The link time can be either reset on startup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) or reported as is (the latter being useful to compare progress of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) different streams - but may require the wallclock to be always
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) running and not wrap-around during idle periods). If supported in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) hardware, the absolute link time could also be used to define a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) precise start time (patches WIP)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) - including the delay in the audio timestamp may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) counter-intuitively not increase the precision of timestamps, e.g. if a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) codec includes variable-latency DSP processing or a chain of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) hardware components the delay is typically not known with precision.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) The accuracy is reported in nanosecond units (using an unsigned 32-bit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) word), which gives a max precision of 4.29s, more than enough for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) audio applications...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) Due to the varied nature of timestamping needs, even for a single
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) application, the audio_tstamp_config can be changed dynamically. In
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) the ``STATUS`` ioctl, the parameters are read-only and do not allow for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) any application selection. To work around this limitation without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) impacting legacy applications, a new ``STATUS_EXT`` ioctl is introduced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) with read/write parameters. ALSA-lib will be modified to make use of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) ``STATUS_EXT`` and effectively deprecate ``STATUS``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) The ALSA API only allows for a single audio timestamp to be reported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) at a time. This is a conscious design decision, reading the audio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) timestamps from hardware registers or from IPC takes time, the more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) timestamps are read the more imprecise the combined measurements
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) are. To avoid any interpretation issues, a single (system, audio)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) timestamp is reported. Applications that need different timestamps
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) will be required to issue multiple queries and perform an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) interpolation of the results
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) In some hardware-specific configuration, the system timestamp is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) latched by a low-level audio subsystem, and the information provided
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) back to the driver. Due to potential delays in the communication with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) the hardware, there is a risk of misalignment with the avail and delay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) information. To make sure applications are not confused, a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) driver_timestamp field is added in the snd_pcm_status structure; this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) timestamp shows when the information is put together by the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) before returning from the ``STATUS`` and ``STATUS_EXT`` ioctl. in most cases
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) this driver_timestamp will be identical to the regular system tstamp.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) Examples of timestamping with HDAudio:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) 1. DMA timestamp, no compensation for DMA+analog delay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) $ ./audio_time -p --ts_type=1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) playback: systime: 341121338 nsec, audio time 342000000 nsec, systime delta -878662
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) playback: systime: 426236663 nsec, audio time 427187500 nsec, systime delta -950837
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) playback: systime: 597080580 nsec, audio time 598000000 nsec, systime delta -919420
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) playback: systime: 682059782 nsec, audio time 683020833 nsec, systime delta -961051
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) playback: systime: 852896415 nsec, audio time 853854166 nsec, systime delta -957751
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) playback: systime: 937903344 nsec, audio time 938854166 nsec, systime delta -950822
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) 2. DMA timestamp, compensation for DMA+analog delay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) $ ./audio_time -p --ts_type=1 -d
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) playback: systime: 341053347 nsec, audio time 341062500 nsec, systime delta -9153
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) playback: systime: 426072447 nsec, audio time 426062500 nsec, systime delta 9947
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) playback: systime: 596899518 nsec, audio time 596895833 nsec, systime delta 3685
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) playback: systime: 681915317 nsec, audio time 681916666 nsec, systime delta -1349
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) playback: systime: 852741306 nsec, audio time 852750000 nsec, systime delta -8694
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) 3. link timestamp, compensation for DMA+analog delay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) $ ./audio_time -p --ts_type=2 -d
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) playback: systime: 341060004 nsec, audio time 341062791 nsec, systime delta -2787
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) playback: systime: 426242074 nsec, audio time 426244875 nsec, systime delta -2801
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) playback: systime: 597080992 nsec, audio time 597084583 nsec, systime delta -3591
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) playback: systime: 682084512 nsec, audio time 682088291 nsec, systime delta -3779
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) playback: systime: 852936229 nsec, audio time 852940916 nsec, systime delta -4687
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -5146
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) Example 1 shows that the timestamp at the DMA level is close to 1ms
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) ahead of the actual playback time (as a side time this sort of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) measurement can help define rewind safeguards). Compensating for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) DMA-link delay in example 2 helps remove the hardware buffering but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) the information is still very jittery, with up to one sample of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) error. In example 3 where the timestamps are measured with the link
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) wallclock, the timestamps show a monotonic behavior and a lower
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) dispersion.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) Example 3 and 4 are with USB audio class. Example 3 shows a high
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) offset between audio time and system time due to buffering. Example 4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) shows how compensating for the delay exposes a 1ms accuracy (due to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) the use of the frame counter by the driver)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) Example 3: DMA timestamp, no compensation for delay, delta of ~5ms
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) $ ./audio_time -p -Dhw:1 -t1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) playback: systime: 120174019 nsec, audio time 125000000 nsec, systime delta -4825981
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) playback: systime: 245041136 nsec, audio time 250000000 nsec, systime delta -4958864
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) playback: systime: 370106088 nsec, audio time 375000000 nsec, systime delta -4893912
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) playback: systime: 495040065 nsec, audio time 500000000 nsec, systime delta -4959935
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) playback: systime: 620038179 nsec, audio time 625000000 nsec, systime delta -4961821
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) playback: systime: 745087741 nsec, audio time 750000000 nsec, systime delta -4912259
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) playback: systime: 870037336 nsec, audio time 875000000 nsec, systime delta -4962664
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) Example 4: DMA timestamp, compensation for delay, delay of ~1ms
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) $ ./audio_time -p -Dhw:1 -t1 -d
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) playback: systime: 120190520 nsec, audio time 120000000 nsec, systime delta 190520
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) playback: systime: 245036740 nsec, audio time 244000000 nsec, systime delta 1036740
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) playback: systime: 370034081 nsec, audio time 369000000 nsec, systime delta 1034081
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) playback: systime: 495159907 nsec, audio time 494000000 nsec, systime delta 1159907
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) playback: systime: 620098824 nsec, audio time 619000000 nsec, systime delta 1098824
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) playback: systime: 745031847 nsec, audio time 744000000 nsec, systime delta 1031847
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags