[alsa-devel] snd_pcm_wait function (really snd_pcm_draiin)
daniellsanz2 at gmail.com
Mon Nov 19 12:10:54 CET 2012
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:
usleep(delay * microseconds_per_frame);
Similar workarounds are implemented in other software, like Mplayer, I believe.
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.
More information about the Alsa-devel