Yes, David, you are right, it's actually pulseaudio blocking for about 2 seconds after the sound is played. You can see it by tracing an application that calls snd_pcm_drain using strace -tt.
I think I worked around the problem by sleeping before calling snd_pcm_drain: ... snd_pcm_delay(handle, &delay); usleep(delay * microseconds_per_frame); snd_pcm_drain(handle); ...
Similar workarounds are implemented in other software, like Mplayer, I believe.
Regards,
On Fri, Nov 16, 2012 at 8:10 PM, David Henningsson david.henningsson@canonical.com wrote:
On 11/16/2012 05:27 PM, Enno Fennema wrote:
On 11/16/12 11:41, Daniel Sanz wrote:
Thanks, Trent, I've been playing a bit with snd_pcm_drain, snd_pcm_writei, blocking mode, non-blocking mode, etc. but even if I ...
I wanted to play a short sound and release the pcm. It works with a non-block drain as Clemens suggested.
I noticed using gettimeofday() around drain() that it takes a bit over 2 seconds. Rather long for a sound that only takes 0.1 sec.
That is a known pulseaudio problem; which we also noted on PulseConf a few weeks ago. I want to do something about it but it is not on the top of my priority list right now.
Are the rest of you trying with PulseAudio as well? Maybe it could be worth also trying the direct plughw path do see if the behaviour is different.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic