재생 중 스트림 대기 시간

오디오 재생 스트림이 실행 상태에 있는 동안 WaveRT 포트 드라이버의 역할은 최소화됩니다. 다음 다이어그램에 표시된 것처럼 재생 중에 WaveRT 포트 드라이버의 클라이언트는 해당 데이터를 주기적 버퍼에 쓰고 오디오 디바이스는 버퍼에서 이 데이터를 읽습니다. 이 작업에는 포트 드라이버의 개입이 필요하지 않습니다. 즉, 오디오 데이터는 커널 모드 소프트웨어 구성 요소에 의해 터치되지 않고 사용자 모드 애플리케이션과 오디오 하드웨어 간에 직접 흐릅니다.

다이어그램에서 쓰기 및 재생 위치는 오디오 데이터 스트림이 주기적 버퍼를 통해 흐르면서 계속해서 왼쪽에서 오른쪽으로 진행됩니다. 재생 위치 또는 쓰기 위치가 버퍼의 끝에 도달하면 버퍼의 시작 부분에 자동으로 래핑되기 때문에 버퍼는 순환으로 설명됩니다.

재생 중 스트림 대기 시간에는 다음 다이어그램에서 A 및 B로 지정된 두 개의 기본 원본이 있습니다.

앞의 다이어그램에서 쓰기 위치 는 클라이언트가 버퍼에 쓴 마지막 샘플 바로 앞의 위치입니다. 재생 위치는 오디오 디바이스가 현재 스피커를 통해 재생 중인 샘플입니다.

클라이언트가 오디오 샘플을 버퍼에 쓰는 시점부터 오디오 디바이스가 재생될 때까지의 대기 시간은 단순히 쓰기 위치와 재생 위치 간의 분리입니다. 이 분리는 다음 두 개의 대기 시간 원본(다이어그램에서 A와 B로 표시됨)의 합계입니다.

대기 시간 A: 오디오 디바이스가 버퍼에서 데이터를 읽은 후 오디오 디바이스가 DAC(디지털-아날로그 변환기)를 통해 데이터를 클록할 때까지 FIFO(첫 번째, 첫 번째 아웃) 버퍼에 데이터가 상주합니다.

대기 시간 B: 클라이언트가 주기적 버퍼에 데이터를 쓴 후 오디오 디바이스가 데이터를 읽을 때까지 데이터가 버퍼에 상주합니다.

클라이언트는 하드웨어에 전적으로 의존하는 대기 시간 A를 제어할 수 없습니다. 일반적인 FIFO는 샘플 클록의 약 64틱에 대해 DAC에 공급하기에 충분한 샘플을 저장할 수 있습니다. 그러나 클라이언트는 대기 시간 B를 제어합니다. 대기 시간 B를 너무 크게 만들면 시스템에 불필요한 지연이 발생합니다. 그러나 너무 작게 만들면 오디오 디바이스가 고갈될 위험이 있습니다.

클라이언트는 버퍼 작성 스레드를 주기적으로 활성화하도록 타이머를 설정할 수 있지만 이 메서드는 가장 짧은 대기 시간을 달성하지 못합니다. 대기 시간을 더 줄이기 위해 클라이언트는 디바이스가 버퍼에서 새 재생 데이터 블록 읽기를 완료할 때마다 하드웨어 알림을 생성하도록 디바이스를 구성할 수 있습니다. 이 경우 클라이언트 스레드는 타이머가 아닌 하드웨어 알림에 의해 활성화됩니다.

오디오 디바이스가 버퍼에서 데이터 블록 읽기를 완료할 때마다 클라이언트에 알리도록 함으로써 클라이언트는 대기 시간을 실제보다 작게 만들 수 있습니다.

클라이언트는 KSPROPERTY_RTAUDIO_HWLATENCY 요청을 WaveRT 포트 드라이버로 전송하여 스트림 대기 시간에 영향을 주는 지연에 대한 요약을 얻을 수 있습니다.

클라이언트가 쓰기 위치와 재생 위치 간에 유지할 분리 양을 결정한 후 클라이언트는 재생 위치의 변경 내용을 모니터링하여 쓰기 위치를 얼마나 발전시킬지 결정합니다. Windows Server 2008 이상 운영 체제에서 클라이언트는 재생 위치를 결정하기 위해 KSPROPERTY_RTAUDIO_POSITIONREGISTER 속성 요청을 보냅니다. 이 기능에 대한 지원은 PortCls 시스템 드라이버의 향상된 기능을 통해 제공됩니다.

이전 다이어그램에 표시된 것처럼 오디오 디바이스에 위치 레지스터가 있는 경우 속성 요청은 레지스터를 사용자 모드 클라이언트가 액세스할 수 있는 가상 메모리 주소에 매핑합니다. 위치 레지스터가 매핑된 후 클라이언트는 메모리 주소의 내용을 읽고 현재 재생 위치를 확인할 수 있습니다.