요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
=====================
2
ALSA PCM Timestamping
3
=====================
5
The ALSA API can provide two different system timestamps:
7
- Trigger_tstamp is the system time snapshot taken when the .trigger
8
callback is invoked. This snapshot is taken by the ALSA core in the
9
general case, but specific hardware may have synchronization
10
capabilities or conversely may only be able to provide a correct
11
estimate with a delay. In the latter two cases, the low-level driver
12
is responsible for updating the trigger_tstamp at the most appropriate
13
and precise moment. Applications should not rely solely on the first
14
trigger_tstamp but update their internal calculations if the driver
15
provides a refined estimate with a delay.
17
- tstamp is the current system timestamp updated during the last
18
event or application query.
19
The difference (tstamp - trigger_tstamp) defines the elapsed time.
21
The ALSA API provides two basic pieces of information, avail
22
and delay, which combined with the trigger and current system
23
timestamps allow for applications to keep track of the 'fullness' of
24
the ring buffer and the amount of queued samples.
26
The use of these different pointers and time information depends on
27
the application needs:
29
- ``avail`` reports how much can be written in the ring buffer
30
- ``delay`` reports the time it will take to hear a new sample after all
31
queued samples have been played out.
33
When timestamps are enabled, the avail/delay information is reported
34
along with a snapshot of system time. Applications can select from
35
``CLOCK_REALTIME`` (NTP corrections including going backwards),
36
``CLOCK_MONOTONIC`` (NTP corrections but never going backwards),
37
``CLOCK_MONOTIC_RAW`` (without NTP corrections) and change the mode
38
dynamically with sw_params
41
The ALSA API also provide an audio_tstamp which reflects the passage
42
of time as measured by different components of audio hardware. In
43
ascii-art, this could be represented as follows (for the playback
44
case):
45
::
47
--------------------------------------------------------------> time
48
^ ^ ^ ^ ^
49
| | | | |
50
analog link dma app FullBuffer
51
time time time time time
52
| | | | |
53
|< codec delay >|<--hw delay-->|<queued samples>|<---avail->|
54
|<----------------- delay---------------------->| |
55
|<----ring buffer length---->|
58
The analog time is taken at the last stage of the playback, as close
59
as possible to the actual transducer
61
The link time is taken at the output of the SoC/chipset as the samples
62
are pushed on a link. The link time can be directly measured if
63
supported in hardware by sample counters or wallclocks (e.g. with
64
HDAudio 24MHz or PTP clock for networked solutions) or indirectly
65
estimated (e.g. with the frame counter in USB).
67
The DMA time is measured using counters - typically the least reliable
68
of all measurements due to the bursty nature of DMA transfers.
70
The app time corresponds to the time tracked by an application after
71
writing in the ring buffer.
73
The application can query the hardware capabilities, define which
74
audio time it wants reported by selecting the relevant settings in
75
audio_tstamp_config fields, thus get an estimate of the timestamp
76
accuracy. It can also request the delay-to-analog be included in the
77
measurement. Direct access to the link time is very interesting on
78
platforms that provide an embedded DSP; measuring directly the link
79
time with dedicated hardware, possibly synchronized with system time,
80
removes the need to keep track of internal DSP processing times and
81
latency.
83
In case the application requests an audio tstamp that is not supported
84
in hardware/low-level driver, the type is overridden as DEFAULT and the
85
timestamp will report the DMA time based on the hw_pointer value.
87
For backwards compatibility with previous implementations that did not
88
provide timestamp selection, with a zero-valued COMPAT timestamp type
89
the results will default to the HDAudio wall clock for playback
90
streams and to the DMA time (hw_ptr) in all other cases.
92
The audio timestamp accuracy can be returned to user-space, so that
93
appropriate decisions are made:
95
- for dma time (default), the granularity of the transfers can be
96
inferred from the steps between updates and in turn provide
97
information on how much the application pointer can be rewound
98
safely.
100
- the link time can be used to track long-term drifts between audio
101
and system time using the (tstamp-trigger_tstamp)/audio_tstamp
102
ratio, the precision helps define how much smoothing/low-pass
103
filtering is required. The link time can be either reset on startup
104
or reported as is (the latter being useful to compare progress of
105
different streams - but may require the wallclock to be always
106
running and not wrap-around during idle periods). If supported in
107
hardware, the absolute link time could also be used to define a
108
precise start time (patches WIP)
110
- including the delay in the audio timestamp may
111
counter-intuitively not increase the precision of timestamps, e.g. if a
112
codec includes variable-latency DSP processing or a chain of
113
hardware components the delay is typically not known with precision.
115
The accuracy is reported in nanosecond units (using an unsigned 32-bit
116
word), which gives a max precision of 4.29s, more than enough for
117
audio applications...
119
Due to the varied nature of timestamping needs, even for a single
120
application, the audio_tstamp_config can be changed dynamically. In
121
the ``STATUS`` ioctl, the parameters are read-only and do not allow for
122
any application selection. To work around this limitation without
123
impacting legacy applications, a new ``STATUS_EXT`` ioctl is introduced
124
with read/write parameters. ALSA-lib will be modified to make use of
125
``STATUS_EXT`` and effectively deprecate ``STATUS``.
127
The ALSA API only allows for a single audio timestamp to be reported
128
at a time. This is a conscious design decision, reading the audio
129
timestamps from hardware registers or from IPC takes time, the more
130
timestamps are read the more imprecise the combined measurements
131
are. To avoid any interpretation issues, a single (system, audio)
132
timestamp is reported. Applications that need different timestamps
133
will be required to issue multiple queries and perform an
134
interpolation of the results
136
In some hardware-specific configuration, the system timestamp is
137
latched by a low-level audio subsystem, and the information provided
138
back to the driver. Due to potential delays in the communication with
139
the hardware, there is a risk of misalignment with the avail and delay
140
information. To make sure applications are not confused, a
141
driver_timestamp field is added in the snd_pcm_status structure; this
142
timestamp shows when the information is put together by the driver
143
before returning from the ``STATUS`` and ``STATUS_EXT`` ioctl. in most cases
144
this driver_timestamp will be identical to the regular system tstamp.
146
Examples of timestamping with HDAudio:
148
1. DMA timestamp, no compensation for DMA+analog delay
149
::
151
$ ./audio_time -p --ts_type=1
152
playback: systime: 341121338 nsec, audio time 342000000 nsec, systime delta -878662
153
playback: systime: 426236663 nsec, audio time 427187500 nsec, systime delta -950837
154
playback: systime: 597080580 nsec, audio time 598000000 nsec, systime delta -919420
155
playback: systime: 682059782 nsec, audio time 683020833 nsec, systime delta -961051
156
playback: systime: 852896415 nsec, audio time 853854166 nsec, systime delta -957751
157
playback: systime: 937903344 nsec, audio time 938854166 nsec, systime delta -950822
159
2. DMA timestamp, compensation for DMA+analog delay
160
::
162
$ ./audio_time -p --ts_type=1 -d
163
playback: systime: 341053347 nsec, audio time 341062500 nsec, systime delta -9153
164
playback: systime: 426072447 nsec, audio time 426062500 nsec, systime delta 9947
165
playback: systime: 596899518 nsec, audio time 596895833 nsec, systime delta 3685
166
playback: systime: 681915317 nsec, audio time 681916666 nsec, systime delta -1349
167
playback: systime: 852741306 nsec, audio time 852750000 nsec, systime delta -8694
169
3. link timestamp, compensation for DMA+analog delay
170
::
172
$ ./audio_time -p --ts_type=2 -d
173
playback: systime: 341060004 nsec, audio time 341062791 nsec, systime delta -2787
174
playback: systime: 426242074 nsec, audio time 426244875 nsec, systime delta -2801
175
playback: systime: 597080992 nsec, audio time 597084583 nsec, systime delta -3591
176
playback: systime: 682084512 nsec, audio time 682088291 nsec, systime delta -3779
177
playback: systime: 852936229 nsec, audio time 852940916 nsec, systime delta -4687
178
playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -5146
180
Example 1 shows that the timestamp at the DMA level is close to 1ms
181
ahead of the actual playback time (as a side time this sort of
182
measurement can help define rewind safeguards). Compensating for the
183
DMA-link delay in example 2 helps remove the hardware buffering but
184
the information is still very jittery, with up to one sample of
185
error. In example 3 where the timestamps are measured with the link
186
wallclock, the timestamps show a monotonic behavior and a lower
187
dispersion.
189
Example 3 and 4 are with USB audio class. Example 3 shows a high
190
offset between audio time and system time due to buffering. Example 4
191
shows how compensating for the delay exposes a 1ms accuracy (due to
192
the use of the frame counter by the driver)
194
Example 3: DMA timestamp, no compensation for delay, delta of ~5ms
195
::
197
$ ./audio_time -p -Dhw:1 -t1
198
playback: systime: 120174019 nsec, audio time 125000000 nsec, systime delta -4825981
199
playback: systime: 245041136 nsec, audio time 250000000 nsec, systime delta -4958864
200
playback: systime: 370106088 nsec, audio time 375000000 nsec, systime delta -4893912
201
playback: systime: 495040065 nsec, audio time 500000000 nsec, systime delta -4959935
202
playback: systime: 620038179 nsec, audio time 625000000 nsec, systime delta -4961821
203
playback: systime: 745087741 nsec, audio time 750000000 nsec, systime delta -4912259
204
playback: systime: 870037336 nsec, audio time 875000000 nsec, systime delta -4962664
206
Example 4: DMA timestamp, compensation for delay, delay of ~1ms
207
::
209
$ ./audio_time -p -Dhw:1 -t1 -d
210
playback: systime: 120190520 nsec, audio time 120000000 nsec, systime delta 190520
211
playback: systime: 245036740 nsec, audio time 244000000 nsec, systime delta 1036740
212
playback: systime: 370034081 nsec, audio time 369000000 nsec, systime delta 1034081
213
playback: systime: 495159907 nsec, audio time 494000000 nsec, systime delta 1159907
214
playback: systime: 620098824 nsec, audio time 619000000 nsec, systime delta 1098824
215
playback: systime: 745031847 nsec, audio time 744000000 nsec, systime delta 1031847
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
시스템 타임스탬프와 링 버퍼 상태
1-40ALSA API는 서로 다른 두 종류의 시스템 타임스탬프를 제공할 수 있습니다. `trigger_tstamp`는 `.trigger` 콜백이 호출될 때 채취한 시스템 시각 스냅샷입니다. 일반적으로 ALSA 코어가 이 값을 기록하지만, 특정 하드웨어는 자체 동기화 기능을 제공하거나 반대로 일정 시간이 지난 뒤에야 정확한 추정치를 낼 수 있습니다. 뒤의 두 경우에는 저수준 드라이버가 가장 적절하고 정밀한 순간에 `trigger_tstamp`를 갱신할 책임을 집니다.
애플리케이션은 최초의 `trigger_tstamp`만 전적으로 신뢰해서는 안 됩니다. 드라이버가 지연 후 더 정교한 추정치를 제공하면 내부 계산도 그 값에 맞춰 갱신해야 합니다. `tstamp`는 마지막 이벤트 또는 애플리케이션 질의 때 갱신된 현재 시스템 타임스탬프이며, `tstamp - trigger_tstamp`가 경과 시간을 정의합니다.
ALSA API가 제공하는 기본 상태 정보는 `avail`과 `delay`입니다. 이 두 값에 트리거 시각과 현재 시스템 시각을 결합하면 애플리케이션은 링 버퍼가 얼마나 차 있는지와 큐에 샘플이 얼마나 쌓였는지를 추적할 수 있습니다. `avail`은 링 버퍼에 추가로 쓸 수 있는 양을, `delay`는 큐에 있는 모든 샘플을 재생한 뒤 새 샘플이 실제로 들리기까지 걸리는 시간을 나타냅니다.
타임스탬프를 활성화하면 `avail`과 `delay`가 시스템 시각 스냅샷과 함께 보고됩니다. 애플리케이션은 `sw_params`를 통해 시계 모드를 동적으로 바꿀 수 있습니다. 선택지는 NTP 보정 때문에 뒤로 갈 수도 있는 `CLOCK_REALTIME`, NTP 보정을 적용하되 뒤로 가지 않는 `CLOCK_MONOTONIC`, NTP 보정을 적용하지 않는 원문 표기의 `CLOCK_MONOTIC_RAW`입니다.
항목기준 시점용도 또는 주의점
trigger_tstamp.trigger 콜백 호출 시점드라이버가 나중에 더 정확한 값으로 보정할 수 있음
tstamp마지막 이벤트 또는 질의 시점trigger_tstamp와의 차이가 경과 시간
avail상태 스냅샷링 버퍼에 더 쓸 수 있는 양
delay상태 스냅샷큐 소진 뒤 새 샘플이 들릴 때까지의 시간
clock modesw_params 선택REALTIME, MONOTONIC, 원문 표기 MONOTIC_RAW
각 값이 가리키는 시점과 애플리케이션이 얻는 의미를 구분합니다.
=====================
ALSA PCM Timestamping
=====================
The ALSA API can provide two different system timestamps:
- Trigger_tstamp is the system time snapshot taken when the .trigger
callback is invoked. This snapshot is taken by the ALSA core in the
general case, but specific hardware may have synchronization
capabilities or conversely may only be able to provide a correct
estimate with a delay. In the latter two cases, the low-level driver
is responsible for updating the trigger_tstamp at the most appropriate
and precise moment. Applications should not rely solely on the first
trigger_tstamp but update their internal calculations if the driver
provides a refined estimate with a delay.
- tstamp is the current system timestamp updated during the last
event or application query.
The difference (tstamp - trigger_tstamp) defines the elapsed time.
The ALSA API provides two basic pieces of information, avail
and delay, which combined with the trigger and current system
timestamps allow for applications to keep track of the 'fullness' of
the ring buffer and the amount of queued samples.
The use of these different pointers and time information depends on
the application needs:
- ``avail`` reports how much can be written in the ring buffer
- ``delay`` reports the time it will take to hear a new sample after all
queued samples have been played out.
When timestamps are enabled, the avail/delay information is reported
along with a snapshot of system time. Applications can select from
``CLOCK_REALTIME`` (NTP corrections including going backwards),
``CLOCK_MONOTONIC`` (NTP corrections but never going backwards),
``CLOCK_MONOTIC_RAW`` (without NTP corrections) and change the mode
dynamically with sw_params
오디오 하드웨어 시간축
41-81ALSA API는 오디오 하드웨어의 여러 구성 요소가 측정한 시간의 흐름을 반영하는 `audio_tstamp`도 제공합니다. 재생 경로에서는 애플리케이션이 링 버퍼에 기록한 위치에서 DMA, SoC나 칩셋의 링크 출력, 코덱과 실제 변환기 가까이의 아날로그 단계로 진행하면서 서로 다른 시점을 관측할 수 있습니다.
아날로그 시각은 재생 경로의 마지막 단계, 즉 실제 변환기에 가능한 한 가까운 곳에서 얻습니다. 링크 시각은 샘플이 SoC 또는 칩셋 출력 링크로 밀려나는 지점에서 얻습니다. 하드웨어가 지원하면 HDAudio 24MHz 또는 네트워크 오디오의 PTP 시계 같은 샘플 카운터·벽시계로 직접 측정하고, 그렇지 않으면 USB 프레임 카운터처럼 간접 추정할 수 있습니다.
DMA 시각은 보통 카운터로 측정하지만 DMA 전송이 버스트 형태로 일어나므로 여러 측정 가운데 대체로 신뢰도가 가장 낮습니다. 애플리케이션 시각은 애플리케이션이 링 버퍼에 데이터를 쓴 뒤 추적하는 시각입니다.
애플리케이션은 하드웨어 기능을 질의하고 `audio_tstamp_config` 필드에서 원하는 오디오 시각을 선택하여 타임스탬프 정확도의 추정치도 받을 수 있습니다. 측정값에 아날로그 단계까지의 지연을 포함하도록 요청할 수도 있습니다. 임베디드 DSP가 있는 플랫폼에서는 전용 하드웨어로 링크 시각을 직접 측정하고 가능하면 시스템 시각과 동기화함으로써 DSP 내부 처리 시간과 지연을 별도로 추적하지 않아도 됩니다.
FullBuffer time→app time→DMA time→link time→analog time→실제 변환기
애플리케이션이 쓴 샘플이 실제 출력으로 진행하면서 관측 가능한 타임스탬프 위치를 나타냅니다.
구간시작끝의미
codec delayanalog timelink time코덱을 지나 아날로그 출력에 이르는 지연
hw delaylink timeDMA time하드웨어 링크와 DMA 사이의 지연
queued samplesDMA timeapp time이미 큐에 들어간 샘플
availapp timeFullBuffer time아직 기록할 수 있는 공간
delayanalog timeapp time현재 큐가 실제 출력에 도달하기까지의 전체 지연
ring buffer lengthDMA timeFullBuffer time전체 링 버퍼 길이
ASCII 그림의 각 괄호 구간을 같은 시작점과 끝점으로 구조화했습니다.
The ALSA API also provide an audio_tstamp which reflects the passage
of time as measured by different components of audio hardware. In
ascii-art, this could be represented as follows (for the playback
case):
::
--------------------------------------------------------------> time
^ ^ ^ ^ ^
| | | | |
analog link dma app FullBuffer
time time time time time
| | | | |
|< codec delay >|<--hw delay-->|<queued samples>|<---avail->|
|<----------------- delay---------------------->| |
|<----ring buffer length---->|
The analog time is taken at the last stage of the playback, as close
as possible to the actual transducer
The link time is taken at the output of the SoC/chipset as the samples
are pushed on a link. The link time can be directly measured if
supported in hardware by sample counters or wallclocks (e.g. with
HDAudio 24MHz or PTP clock for networked solutions) or indirectly
estimated (e.g. with the frame counter in USB).
The DMA time is measured using counters - typically the least reliable
of all measurements due to the bursty nature of DMA transfers.
The app time corresponds to the time tracked by an application after
writing in the ring buffer.
The application can query the hardware capabilities, define which
audio time it wants reported by selecting the relevant settings in
audio_tstamp_config fields, thus get an estimate of the timestamp
accuracy. It can also request the delay-to-analog be included in the
measurement. Direct access to the link time is very interesting on
platforms that provide an embedded DSP; measuring directly the link
time with dedicated hardware, possibly synchronized with system time,
removes the need to keep track of internal DSP processing times and
latency.타임스탬프 선택, 정확도와 STATUS_EXT
82-125애플리케이션이 요청한 오디오 타임스탬프를 하드웨어 또는 저수준 드라이버가 지원하지 않으면 타입은 `DEFAULT`로 재정의되고, 타임스탬프는 `hw_pointer` 값을 바탕으로 한 DMA 시각을 보고합니다. 타임스탬프 선택 기능이 없던 과거 구현과의 호환성을 위해 값이 0인 `COMPAT` 타입을 사용하면 재생 스트림에서는 HDAudio 벽시계가 기본값이고, 그 밖의 모든 경우에는 DMA 시각인 `hw_ptr`이 기본값입니다.
오디오 타임스탬프의 정확도는 사용자 공간에 반환되어 애플리케이션이 적절한 결정을 내리게 합니다. 기본 DMA 시각에서는 갱신 사이의 단계로 전송 단위를 추론할 수 있고, 이를 통해 애플리케이션 포인터를 안전하게 얼마나 되감을 수 있는지 판단할 수 있습니다.
링크 시각은 `(tstamp-trigger_tstamp)/audio_tstamp` 비율을 사용하여 오디오 시각과 시스템 시각 사이의 장기 드리프트를 추적하는 데 쓸 수 있습니다. 보고된 정밀도는 필요한 평활화 또는 저역 통과 필터링의 정도를 결정하는 데 도움이 됩니다. 링크 시각은 시작할 때 재설정할 수도 있고 원래 값 그대로 보고할 수도 있습니다. 후자는 여러 스트림의 진행을 비교하는 데 유용하지만, 유휴 시간에도 벽시계가 계속 동작하고 래핑되지 않아야 할 수 있습니다. 하드웨어가 지원한다면 절대 링크 시각으로 정밀한 시작 시각을 정의하는 기능도 구상 중이라고 원문은 밝힙니다.
오디오 타임스탬프에 지연을 포함해도 직관과 달리 정밀도가 높아지지 않을 수 있습니다. 코덱에 가변 지연 DSP 처리가 있거나 여러 하드웨어 구성 요소가 연결된 경우 전체 지연을 정밀하게 알기 어렵기 때문입니다. 정확도는 부호 없는 32비트 값의 나노초 단위로 보고되며, 표현 가능한 최대값은 약 4.29초이므로 오디오 애플리케이션에는 충분합니다.
한 애플리케이션 안에서도 요구가 달라질 수 있으므로 `audio_tstamp_config`는 동적으로 변경할 수 있습니다. 기존 `STATUS` ioctl의 매개변수는 읽기 전용이라 애플리케이션이 선택 값을 전달할 수 없습니다. 기존 애플리케이션에 영향을 주지 않고 이 제약을 피하기 위해 읽기·쓰기가 가능한 매개변수를 갖는 `STATUS_EXT` ioctl이 도입되었습니다. ALSA-lib는 `STATUS_EXT`를 사용하도록 바뀌며 결과적으로 `STATUS`는 사용 중단 방향으로 갑니다.
상황보고되는 시각활용 또는 제약
요청 타입 지원선택한 하드웨어 지점정확도 추정치와 지연 포함 여부를 함께 요청 가능
요청 타입 미지원DEFAULT, hw_pointer 기반 DMA 시각드라이버가 지원 타입으로 대체
COMPAT 재생HDAudio wall clock이전 구현과의 호환
COMPAT 기타DMA 시각(hw_ptr)이전 구현과의 호환
지연 포함선택 시각 + delay가변 DSP 지연 때문에 정밀도가 좋아진다고 보장할 수 없음
요청 타입, 실제 보고 기준, 정확도 활용을 한눈에 정리합니다.
In case the application requests an audio tstamp that is not supported
in hardware/low-level driver, the type is overridden as DEFAULT and the
timestamp will report the DMA time based on the hw_pointer value.
For backwards compatibility with previous implementations that did not
provide timestamp selection, with a zero-valued COMPAT timestamp type
the results will default to the HDAudio wall clock for playback
streams and to the DMA time (hw_ptr) in all other cases.
The audio timestamp accuracy can be returned to user-space, so that
appropriate decisions are made:
- for dma time (default), the granularity of the transfers can be
inferred from the steps between updates and in turn provide
information on how much the application pointer can be rewound
safely.
- the link time can be used to track long-term drifts between audio
and system time using the (tstamp-trigger_tstamp)/audio_tstamp
ratio, the precision helps define how much smoothing/low-pass
filtering is required. The link time can be either reset on startup
or reported as is (the latter being useful to compare progress of
different streams - but may require the wallclock to be always
running and not wrap-around during idle periods). If supported in
hardware, the absolute link time could also be used to define a
precise start time (patches WIP)
- including the delay in the audio timestamp may
counter-intuitively not increase the precision of timestamps, e.g. if a
codec includes variable-latency DSP processing or a chain of
hardware components the delay is typically not known with precision.
The accuracy is reported in nanosecond units (using an unsigned 32-bit
word), which gives a max precision of 4.29s, more than enough for
audio applications...
Due to the varied nature of timestamping needs, even for a single
application, the audio_tstamp_config can be changed dynamically. In
the ``STATUS`` ioctl, the parameters are read-only and do not allow for
any application selection. To work around this limitation without
impacting legacy applications, a new ``STATUS_EXT`` ioctl is introduced
with read/write parameters. ALSA-lib will be modified to make use of
``STATUS_EXT`` and effectively deprecate ``STATUS``.단일 시각 쌍과 driver_timestamp
126-145ALSA API는 한 번에 오디오 타임스탬프 하나만 보고하도록 설계되었습니다. 하드웨어 레지스터나 IPC에서 오디오 시각을 읽는 데 시간이 들고, 여러 값을 읽을수록 결합된 측정이 더 부정확해지기 때문입니다. 해석상의 혼란을 막기 위해 `(system, audio)` 타임스탬프 한 쌍만 반환합니다. 서로 다른 지점의 시각이 필요한 애플리케이션은 여러 번 질의한 뒤 결과를 보간해야 합니다.
일부 하드웨어 구성에서는 저수준 오디오 서브시스템이 시스템 타임스탬프를 래치한 뒤 그 정보를 드라이버에 돌려줍니다. 하드웨어와 통신하는 동안 지연이 생기면 이 시각이 `avail` 및 `delay` 정보와 어긋날 위험이 있습니다.
애플리케이션이 혼동하지 않도록 `snd_pcm_status` 구조체에 `driver_timestamp` 필드가 추가되었습니다. 이 값은 드라이버가 `STATUS` 또는 `STATUS_EXT` ioctl에서 반환하기 직전에 관련 정보를 한데 모은 시점을 나타냅니다. 대부분의 경우 `driver_timestamp`는 일반 시스템 `tstamp`와 같습니다.
저수준 서브시스템이 시스템 시각 래치→하드웨어 통신→드라이버가 avail·delay·시각 조립→driver_timestamp 기록→STATUS / STATUS_EXT 반환
일반적인 경로→system tstamp→driver_timestamp와 동일
하드웨어가 래치한 시각과 드라이버가 상태를 조립한 시각을 분리해 지연으로 인한 불일치를 드러냅니다.
The ALSA API only allows for a single audio timestamp to be reported
at a time. This is a conscious design decision, reading the audio
timestamps from hardware registers or from IPC takes time, the more
timestamps are read the more imprecise the combined measurements
are. To avoid any interpretation issues, a single (system, audio)
timestamp is reported. Applications that need different timestamps
will be required to issue multiple queries and perform an
interpolation of the results
In some hardware-specific configuration, the system timestamp is
latched by a low-level audio subsystem, and the information provided
back to the driver. Due to potential delays in the communication with
the hardware, there is a risk of misalignment with the avail and delay
information. To make sure applications are not confused, a
driver_timestamp field is added in the snd_pcm_status structure; this
timestamp shows when the information is put together by the driver
before returning from the ``STATUS`` and ``STATUS_EXT`` ioctl. in most cases
this driver_timestamp will be identical to the regular system tstamp.
HDAudio 측정 예
146-187첫 번째 HDAudio 예는 DMA 타임스탬프를 사용하고 DMA와 아날로그 지연을 보상하지 않습니다. 시스템 시각과 오디오 시각의 차이가 대략 -0.88ms에서 -0.96ms로 나타납니다.
$ ./audio_time -p --ts_type=1
playback: systime: 341121338 nsec, audio time 342000000 nsec, systime delta -878662
playback: systime: 426236663 nsec, audio time 427187500 nsec, systime delta -950837
playback: systime: 597080580 nsec, audio time 598000000 nsec, systime delta -919420
playback: systime: 682059782 nsec, audio time 683020833 nsec, systime delta -961051
playback: systime: 852896415 nsec, audio time 853854166 nsec, systime delta -957751
playback: systime: 937903344 nsec, audio time 938854166 nsec, systime delta -950822두 번째 예는 같은 DMA 타임스탬프에 DMA와 아날로그 지연 보상을 적용합니다. 차이는 약 -9.2us에서 +9.9us 범위로 줄지만 샘플마다 부호와 크기가 흔들립니다.
$ ./audio_time -p --ts_type=1 -d
playback: systime: 341053347 nsec, audio time 341062500 nsec, systime delta -9153
playback: systime: 426072447 nsec, audio time 426062500 nsec, systime delta 9947
playback: systime: 596899518 nsec, audio time 596895833 nsec, systime delta 3685
playback: systime: 681915317 nsec, audio time 681916666 nsec, systime delta -1349
playback: systime: 852741306 nsec, audio time 852750000 nsec, systime delta -8694세 번째 예는 링크 타임스탬프와 DMA·아날로그 지연 보상을 함께 사용합니다. 차이는 약 -2.8us에서 -5.1us로 단조롭게 변하며 분산도 더 작습니다.
$ ./audio_time -p --ts_type=2 -d
playback: systime: 341060004 nsec, audio time 341062791 nsec, systime delta -2787
playback: systime: 426242074 nsec, audio time 426244875 nsec, systime delta -2801
playback: systime: 597080992 nsec, audio time 597084583 nsec, systime delta -3591
playback: systime: 682084512 nsec, audio time 682088291 nsec, systime delta -3779
playback: systime: 852936229 nsec, audio time 852940916 nsec, systime delta -4687
playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -5146예 1에서 DMA 수준의 타임스탬프는 실제 재생 시각보다 약 1ms 앞서며, 이런 측정은 되감기 안전 한계를 정하는 데도 활용할 수 있습니다. 예 2에서 DMA-링크 지연을 보상하면 하드웨어 버퍼링의 영향은 제거되지만 정보에는 여전히 최대 한 샘플 정도의 오차와 지터가 있습니다. 예 3처럼 링크 벽시계로 측정하면 타임스탬프가 단조로운 움직임과 더 낮은 분산을 보입니다.
예측정지연 보상관찰 결과
1DMA없음실제 재생보다 약 1ms 앞섬
2DMADMA+analog버퍼 오프셋은 줄지만 최대 한 샘플 지터
3link wallclockDMA+analog단조로운 변화와 더 낮은 분산
동일한 재생 경로에서 측정 지점과 지연 보상이 오차 특성을 어떻게 바꾸는지 비교합니다.
Examples of timestamping with HDAudio:
1. DMA timestamp, no compensation for DMA+analog delay
::
$ ./audio_time -p --ts_type=1
playback: systime: 341121338 nsec, audio time 342000000 nsec, systime delta -878662
playback: systime: 426236663 nsec, audio time 427187500 nsec, systime delta -950837
playback: systime: 597080580 nsec, audio time 598000000 nsec, systime delta -919420
playback: systime: 682059782 nsec, audio time 683020833 nsec, systime delta -961051
playback: systime: 852896415 nsec, audio time 853854166 nsec, systime delta -957751
playback: systime: 937903344 nsec, audio time 938854166 nsec, systime delta -950822
2. DMA timestamp, compensation for DMA+analog delay
::
$ ./audio_time -p --ts_type=1 -d
playback: systime: 341053347 nsec, audio time 341062500 nsec, systime delta -9153
playback: systime: 426072447 nsec, audio time 426062500 nsec, systime delta 9947
playback: systime: 596899518 nsec, audio time 596895833 nsec, systime delta 3685
playback: systime: 681915317 nsec, audio time 681916666 nsec, systime delta -1349
playback: systime: 852741306 nsec, audio time 852750000 nsec, systime delta -8694
3. link timestamp, compensation for DMA+analog delay
::
$ ./audio_time -p --ts_type=2 -d
playback: systime: 341060004 nsec, audio time 341062791 nsec, systime delta -2787
playback: systime: 426242074 nsec, audio time 426244875 nsec, systime delta -2801
playback: systime: 597080992 nsec, audio time 597084583 nsec, systime delta -3591
playback: systime: 682084512 nsec, audio time 682088291 nsec, systime delta -3779
playback: systime: 852936229 nsec, audio time 852940916 nsec, systime delta -4687
playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -5146
Example 1 shows that the timestamp at the DMA level is close to 1ms
ahead of the actual playback time (as a side time this sort of
measurement can help define rewind safeguards). Compensating for the
DMA-link delay in example 2 helps remove the hardware buffering but
the information is still very jittery, with up to one sample of
error. In example 3 where the timestamps are measured with the link
wallclock, the timestamps show a monotonic behavior and a lower
dispersion.USB Audio Class 측정 예
188-215이어지는 USB Audio Class 예는 원문에서 예 3과 예 4로 번호를 다시 사용합니다. USB 예 3은 지연 보상 없이 DMA 타임스탬프를 사용하며, 버퍼링 때문에 오디오 시각과 시스템 시각 사이에 약 5ms의 큰 오프셋이 생깁니다.
$ ./audio_time -p -Dhw:1 -t1
playback: systime: 120174019 nsec, audio time 125000000 nsec, systime delta -4825981
playback: systime: 245041136 nsec, audio time 250000000 nsec, systime delta -4958864
playback: systime: 370106088 nsec, audio time 375000000 nsec, systime delta -4893912
playback: systime: 495040065 nsec, audio time 500000000 nsec, systime delta -4959935
playback: systime: 620038179 nsec, audio time 625000000 nsec, systime delta -4961821
playback: systime: 745087741 nsec, audio time 750000000 nsec, systime delta -4912259
playback: systime: 870037336 nsec, audio time 875000000 nsec, systime delta -4962664USB 예 4는 같은 DMA 타임스탬프에 지연 보상을 적용합니다. 보상 뒤에는 드라이버가 프레임 카운터를 사용하기 때문에 약 1ms 수준의 정확도가 드러납니다.
$ ./audio_time -p -Dhw:1 -t1 -d
playback: systime: 120190520 nsec, audio time 120000000 nsec, systime delta 190520
playback: systime: 245036740 nsec, audio time 244000000 nsec, systime delta 1036740
playback: systime: 370034081 nsec, audio time 369000000 nsec, systime delta 1034081
playback: systime: 495159907 nsec, audio time 494000000 nsec, systime delta 1159907
playback: systime: 620098824 nsec, audio time 619000000 nsec, systime delta 1098824
playback: systime: 745031847 nsec, audio time 744000000 nsec, systime delta 1031847원문 예측정지연 보상관찰 결과
3DMA없음버퍼링에 따른 약 5ms 오프셋
4DMA적용프레임 카운터 한계에 따른 약 1ms 정확도
버퍼 지연 보상 전후에 관측되는 시스템 시각과 오디오 시각의 차이를 정리합니다.
Example 3 and 4 are with USB audio class. Example 3 shows a high
offset between audio time and system time due to buffering. Example 4
shows how compensating for the delay exposes a 1ms accuracy (due to
the use of the frame counter by the driver)
Example 3: DMA timestamp, no compensation for delay, delta of ~5ms
::
$ ./audio_time -p -Dhw:1 -t1
playback: systime: 120174019 nsec, audio time 125000000 nsec, systime delta -4825981
playback: systime: 245041136 nsec, audio time 250000000 nsec, systime delta -4958864
playback: systime: 370106088 nsec, audio time 375000000 nsec, systime delta -4893912
playback: systime: 495040065 nsec, audio time 500000000 nsec, systime delta -4959935
playback: systime: 620038179 nsec, audio time 625000000 nsec, systime delta -4961821
playback: systime: 745087741 nsec, audio time 750000000 nsec, systime delta -4912259
playback: systime: 870037336 nsec, audio time 875000000 nsec, systime delta -4962664
Example 4: DMA timestamp, compensation for delay, delay of ~1ms
::
$ ./audio_time -p -Dhw:1 -t1 -d
playback: systime: 120190520 nsec, audio time 120000000 nsec, systime delta 190520
playback: systime: 245036740 nsec, audio time 244000000 nsec, systime delta 1036740
playback: systime: 370034081 nsec, audio time 369000000 nsec, systime delta 1034081
playback: systime: 495159907 nsec, audio time 494000000 nsec, systime delta 1159907
playback: systime: 620098824 nsec, audio time 619000000 nsec, systime delta 1098824
playback: systime: 745031847 nsec, audio time 744000000 nsec, systime delta 1031847
요약·해설
timestamping.rst:1-215ALSA PCM의 시스템 타임스탬프와 하드웨어 오디오 타임스탬프를 구분하고, `avail`·`delay`, DMA·링크·아날로그 측정 지점, 정확도 보고, `STATUS_EXT`, HDAudio와 USB의 지연 보상 결과를 설명합니다.