O utilitário “play” no Linux realmente tem um “atraso” para parar o processo com arquivos realmente pequenos?

Question

Eu tenho um arquivo wav, Duração: 00: 00: 00.17 (menos de um segundo!)

Quando eu chamo play para executá-lo, play o executa bem, mas meu terminal fica ocioso por ~ 4s até que o processo de reprodução seja concluído.

Isso é por design? É possível apenas tocar o som e ser feito em menos de um segundo?

EDITAR : executando time como sugerido por @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

    

Answer 1

Eu acho que isso é normal latência do sistema de som (principalmente buffer), bem como um artefato de fluxo de programa (buffers, i / o síncrona, polling). O buffer de toque que está sendo reproduzido é presumivelmente muito maior do que a amostra insignificante com duração de apenas 00: 00: 00,17 segundos.

Esse atraso é proporcional à duração da amostra? Ou seja, uma amostra mais longa tem um atraso menor? Eu esperaria uma amostra de tamanho maior (digamos um segundo ou dois inteiros) para reduzir esse tipo de atraso.

O som pode ser algo realmente complicado, especialmente se você olhar para o âmago da questão. Se o que eu disse acima for verdade (com relação a um tamanho maior de amostra) eu diria que isso é normal para qualquer subsistema de som que você esteja usando.

Eu mesmo uso pulseaudio para coisas de baixa latência (como armas em jogos), mas o problema que você descreveu não está realmente relacionado à baixa latência; é mais uma questão do software aguardar o hardware avisar quando é feito o buffer inteiro, que é maior do que a amostra que ele continha.

Se eu estiver errado sobre algo, por favor, indique para mim. Obrigado :)