[alsa-devel] snd_pcm_wait function (really snd_pcm_draiin)

[Daniel Sanz]

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 at 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