오디오 서버(내 경우에는 파이프라인)를 사용하면 "지연"을 변경할 수 있다는 것을 알았습니다. (죄송합니다. 저는 이런 것들에 대해 아는 것이 별로 없습니다.)
PIPEWIRE_LATENCY="128/48000"
Arch Linux 위키에서는 이를 "사용자 정의 버퍼 크기 요청"으로 설명합니다.
대기 시간을 매우 낮게 설정하는 데 "단점"이 있는지 궁금합니다. 반응성이 뛰어난 오디오는 단순히 리소스 비용이 더 높다는 뜻인가요?
답변1
버퍼가 작을수록 더 빨리 채워지고 더 빨리 비워집니다. 이것이 지연 시간이 단축되는 이유입니다.
그러나 데이터를 버퍼에 넣고 버퍼에서 데이터를 가져오는 프로세스는 더 자주 트리거됩니다. 따라서 버퍼를 너무 작게 설정하면 오디오 소프트웨어가 컴퓨터 CPU를 더 많이 소모할 수 있습니다. 극단적인 경우, 버퍼가 더 작은 오디오 시스템을 사용하면 컴퓨터의 다른 소프트웨어가 더 느리게 반응할 수 있습니다. 또는 부드러움과 정지를 번갈아가며 "더듬거림" 또는 "더듬거림"이 발생할 수 있습니다.
작은 버퍼는 오디오 데이터를 버퍼에 넣는 프로세스가 충분히 빠르게 응답할 수 없고 짧은 시간 내에 버퍼가 완전히 비게 되는 경우 오디오 스트림에서 끊김 현상을 일으킬 수도 있습니다. 버퍼에서 오디오 데이터를 가져와 출력을 통해 스피커(또는 헤드폰)로 전달하는 과정에서 데이터가 소진되고 사운드가 중단(흔히 "드롭아웃"이라고 함)을 경험하게 됩니다.
어떤 크기가 "너무 작을지" 예측하기 어렵기 때문에 오디오 스트림과 컴퓨터의 다른 부분에 영향을 주지 않고 가장 짧은 대기 시간을 제공하는 타협안을 실험해야 할 수도 있습니다.
답변2
사운드 응용 프로그램(A), 사운드 서버(B), alsa 사운드 카드 드라이버(C)에 관계없이:
- (A) 샘플을 (자체 속도 PA로) 일부 버퍼에 기록합니다.
- (B) 일부 버퍼에 (해당 속도로) 쓰기 위해 (해당 속도로) 읽습니다.
- 사운드 카드의 인터럽트 핸들러는 (PC의 일정 속도에서) 하드웨어 사운드 카드의 일반적으로 고정 크기의 매우 작은 버퍼를 읽어 들입니다.
- 임베디드 소프트웨어는 이 데이터를 읽어 매우 정확한 속도로 하드웨어 출력에 다시 반영합니다.
이러한 작업 방식을 통해 다음을 이해할 수 있습니다.
- (즉시) 방법이 없어요”지연 설정". ((A) 샘플을 출력하는 시점부터 해당 샘플을 출력하는 하드웨어까지 걸리는 시간으로 이해될 수 있습니다.) 따라서..."대기 시간을 매우 낮게 설정하는 단점"
- 프로세스에 관련된 다양한 구성 요소가 비동기식으로 작동하기 때문에 버퍼가 필요하므로 버퍼 크기는 일부(?) 때로는 일부 업스트림 구성 요소가 바로 뒤따르는 구성 요소보다 더 많은(또는 더 적은) 샘플을 출력한다는 점을 고려해야 합니다. .
이전 단락에서 버퍼 측면에서 다음을 이해할 수 있습니다.
버퍼 크기가 너무 작으면 링 버퍼일 가능성이 높습니다... 오버플로가 발생할 수 있습니다!
즉, 샘플은 하드웨어 출력으로 전달되지 않으며, 이는 가청 사운드로 변환됩니다.
그렇죠! 버퍼 크기를 줄이면 다음과 같은 단점이 있습니다.과잉 지출.
물론 한도 초과 위험을 줄이는 방법도 있습니다. 프로세스를 적절한 속도로 실행하세요!
다운스트림 구성 요소가 적시에(업스트림 구성 요소보다 더 빠르거나 동일한 속도로) 작업을 완료하도록 할 수 있다면 버퍼 크기에 관계없이 오버플로 위험을 방지할 수 있습니다.
- 먼저 irq가 스레드되고 사운드 카드와 관련된 커널 스레드의 실시간 우선 순위가 최대인지 확인하십시오.
- 다음은 위의 irq 커널 스레드 우선순위보다 바로 낮은 우선순위를 갖는 일부 실시간 스케줄링 모델에서 실행되는 사운드 서버여야 합니다.
- 궁극적으로 업스트림 애플리케이션도 실시간 예약 모델에 따라 실행되며 사운드 서버보다 우선순위가 낮습니다.
또한 두 개의 버퍼가 있는 사운드 서버는 비용이 많이 들고(추가 대기 시간 측면에서)... 아무 쓸모가 없으며... 제거를 고려한다고 (정확하게) 생각할 수도 있습니다.