Linux의 "재생" 유틸리티에는 매우 작은 파일을 처리하는 프로세스를 중지하기 위한 "지연"이 실제로 있습니까?

Linux의 "재생" 유틸리티에는 매우 작은 파일을 처리하는 프로세스를 중지하기 위한 "지연"이 실제로 있습니까?

지속 시간이 00:00:00.17(1초 미만!)인 wav 파일이 있습니다.

play실행을 호출하면 play정상적으로 실행되지만 재생 프로세스가 완료될 때까지 터미널은 약 4초 동안 유휴 상태입니다.

이것은 의도적으로 설계된 것입니까? 사운드를 재생하고 1초 이내에 완료하는 것이 가능합니까?

편집하다: time제안된 대로 실행@jsbillings:

 File Size: 1.89k     Bit Rate: 90.3k
  Encoding: Unsigned PCM  
  Channels: 1 @ 8-bit    
Samplerate: 11025Hz      
Replaygain: off         
  Duration: 00:00:00.17  

In:100%  00:00:00.17 [00:00:00.00] Out:1.85k [!=====|=====!]        Clip:0    
Done.

real    0m2.912s
user    0m0.004s
sys         0m0.008s

답변1

나는 이것이 정상적인 사운드 시스템 대기 시간(주로 버퍼링)이자 프로그램 흐름(버퍼, 동기 I/O, 폴링)의 인공물이라고 생각합니다. 재생되는 링 버퍼는 아마도 00:00:00.17초 동안만 지속되는 빈약한 샘플보다 훨씬 클 것입니다.

이 지연은 샘플 기간에 비례합니까? 즉, 샘플이 길수록 지연이 더 작아지나요? 이러한 지연을 줄이기 위해 더 큰 샘플(예: 1~2초)을 사용하고 싶습니다.

사운드는 매우 까다로울 수 있으며, 특히 세부 사항에 접근할 때 더욱 그렇습니다. 위에서 말한 내용이 (더 긴 샘플 크기와 관련하여) 사실이라면 사용하는 사운드 하위 시스템에 관계없이 이것이 정상이라고 말하고 싶습니다.

나 자신은 지연 시간이 짧은 항목(예: 게임의 총)에 펄스 오디오를 사용하지만 설명하는 문제는 실제로 낮은 지연 시간과 관련된 것이 아니라 하드웨어가 전체 버퍼를 재생할 시기를 알려줄 때까지 기다리는 소프트웨어의 문제입니다. 포함된 샘플보다 큽니다.

제가 틀린 부분이 있다면 지적해 주세요. 감사해요:)

관련 정보