0

I have a wav file, Duration: 00:00:00.17 (less than a second!)

When I call play to execute it, play executes it fine, but my terminal becomes idle for ~4s until play process is done.

Is this by design? Is it possible to just play the sound and be done in less than a second?

EDIT: Running time as suggested by @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
Improve this question
  • 1
    Normally, play shouldn't be adding a delay. Try running time play sound.wav (replacing sound.wav with 0.17 second long wav file). – jsbillings Feb 8 '11 at 16:12
  • @jsbillings: I've added time. Thanks for the suggestion. – Somebody still uses you MS-DOS Feb 8 '11 at 21:20
  • Try aplay instead of play. Still a bit of overhead, but a lot less. The file is /usr/share/sounds/k3b_wait_media1.wav right? :) – chris Feb 9 '11 at 14:07
  • 1
    play doesn't normally have such a delay. Do you observe the delay with other files or on other machines? Can you put up the file on the web so other people may test on their machine? Are you running a sound server (PulseAudio, Esd, …)? The output of strace -s9999 -rtt might show what's going on. – Gilles 'SO- stop being evil' Feb 9 '11 at 22:38
  • @jsbillings: Yes, running strace says that I'm using PulseAudio. Using aplay as suggested by @chris does the same delay. So, it means I'll have to just live with it? – Somebody still uses you MS-DOS Feb 10 '11 at 15:36
1

I think this is normal sound system latency (mainly buffering) as well as an artifact of program flow (buffers, synchronous i/o, polling). The ring buffer[s] being played are presumably much larger than the puny sample lasting for only 00:00:00.17 seconds.

Is this delay proportional to the duration of the sample? Ie, does a longer sample have a smaller delay? I would expect a sample of greater size (say a full second or two) to reduce these kinds of delays.

Sound can be really tricky stuff, especially if you look into the nitty gritty. If what I've said above is true (regarding a longer sample size) I'd say this is normal for whatever sound subsystem you're using.

I myself use pulseaudio for low-latency stuff (like guns in games), but the problem you described isn't really related to low latency; it's more a question of the software waiting for the hardware to tell it when it's done playing the whole buffer, which is larger than the sample it contained.

If I'm wrong about something, please point it out to me. Thanks :)

Improve this answer
  • This answer makes sense. Do you know if it's possible to make play (or other utility) opened like a daemon, and when play is called it just executes the sound without this delay? – Somebody still uses you MS-DOS Mar 7 '11 at 21:29
  • 2
    It would help to know what your goal for this is. In game programming for instance, such an event(mixing a sound clip in with other sounds) would be asynchronous in that all sounds are mixed together (the sound buffer will still take a while to be flushed, which might contribute to the shutdown duration of the game). You only notice this "delay" because the clip is so very short and you want to return to the console. Music players background/thread the decoding, separating playback from the user interface. If that's all you want to do, then background the process("play <file> &"). – gamen Mar 12 '11 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.