녹화 중 스트림 대기 시간

오디오 레코드 스트림이 실행 상태에 있는 동안 WaveRT 포트 드라이버의 역할은 최소화됩니다. 다음 다이어그램에 표시된 것처럼 녹음 프로세스 중에 오디오 디바이스는 오디오 데이터를 캡처하고 순환 버퍼에 씁니다. 그런 다음 오디오 엔진은 버퍼에서 이 데이터를 읽습니다. 이 작업에는 포트 드라이버의 개입이 필요하지 않습니다. 즉, 오디오 데이터는 커널 모드 소프트웨어 구성 요소에 의해 터치되지 않고 오디오 하드웨어와 사용자 모드 애플리케이션 간에 직접 흐릅니다.

다음 다이어그램에서는 스트림이 버퍼를 통과할 때 레코드 및 읽기 위치가 왼쪽에서 오른쪽으로 계속 진행됩니다. 레코드 또는 읽기 위치가 버퍼의 끝에 도달하면 버퍼의 시작 부분까지 래핑됩니다.

앞의 다이어그램은 오디오 디바이스가 현재 녹음하고 있는 샘플의 버퍼 위치로 레코드 위치를 식별합니다(아날로그-디지털 변환기 또는 ADC를 통해 마이크에서 캡처). 레코드 위치는 오디오 디바이스가 FIFO를 통과한 후 샘플을 작성하는 향후 버퍼 위치입니다. 읽기 위치는 오디오 엔진이 다음 샘플을 읽는 버퍼 위치입니다.

오디오 디바이스가 ADC에서 오디오 샘플을 캡처하는 시간부터 클라이언트가 읽을 때까지의 대기 시간은 단순히 레코드와 읽기 위치 간의 분리일 뿐입니다. 이 분리는 다음 대기 시간 원본(다이어그램에서 A 및 B로 표시됨)의 합계입니다.

대기 시간 A: ADC에서 데이터를 캡처한 후 오디오 디바이스는 데이터를 순환 버퍼에 쓸 수 있도록 하드웨어 FIFO에 저장합니다.

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

클라이언트는 전적으로 하드웨어에 의존하는 대기 시간 A를 제어할 수 없습니다. 일반적인 FIFO는 ADC에서 약 64개의 샘플을 저장할 수 있습니다. 그러나 클라이언트는 대기 시간 B를 제어합니다. 대기 시간 B를 너무 크게 만들면 시스템에 불필요한 지연이 발생하지만 오디오 디바이스가 버퍼에 기록되기 전에 너무 일찍 데이터를 읽을 위험이 너무 적습니다.

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

오디오 디바이스가 오디오 엔진에 주기적으로 알리면 클라이언트는 대기 시간을 실제보다 작게 만들 수 있습니다.

클라이언트(일반적으로 오디오 엔진)는 waveRT 포트 드라이버에 KSPROPERTY_RTAUDIO_HWLATENCY 요청을 전송하여 오디오 디바이스가 스트림 대기 시간에 기여하는 지연에 대한 요약을 얻을 수 있습니다.

클라이언트가 레코드와 읽기 위치 간에 유지 관리할 분리 양을 결정한 후 클라이언트는 레코드 위치의 변경 내용을 모니터링하여 읽기 위치가 지연되어야 하는 양을 결정합니다. Windows Server 2008 이상 운영 체제에서 클라이언트는 레코드 위치를 확인하기 위해 KSPROPERTY_AUDIO_POSITION 또는 KSPROPERTY_RTAUDIO_POSITIONREGISTER 속성 요청을 보냅니다. 후자의 요청 메서드는 클라이언트가 정보에 대한 커널 모드 루틴으로 전환하지 않고도 레코드 위치를 직접 읽을 수 있기 때문에 더 효율적입니다.