Re: snd_pcm_wait function

Re: snd_pcm_wait function

[Enno Fennema]

Thanks for your reply. I may not have expressed myself clearly. I appear 
to have the opposite problem from Daniel Sanz re Non-blocking 
snd_pcm_drain (also posted 10 Nov). He wants the new sound to start 
immediately. I want to close the pcm AFTER the sound finished.

The docs say calling drain() puts the pcm in the DRAINING state. When I 
obtain the state immediately after drain() it is already SETUP.
I hoped a state change from DRAINING to SETUP  would be the right time 
to close the pcm but there appears to be no such state change.

Currently I solved my problem by a usleep() based on an estimate of the 
time needed to finish playing the last samples in the buffer.

If there is a more elegant way I would like to know. Otherwise I will 
stick with usleep(),

Regards,
Enno

Re: snd_pcm_wait function

[Clemens Ladisch]

Enno Fennema wrote:
> I want to close the pcm AFTER the sound finished.

Then close it after snd_pcm_drain() has returned.

> The docs say calling drain() puts the pcm in the DRAINING state.

It also waits until the device has drained (unless the device is in
non-blocking mode).

> When I obtain the state immediately after drain() it is already SETUP.
> I hoped a state change from DRAINING to SETUP  would be the right time
> to close the pcm but there appears to be no such state change.

That change happens immediately before snd_pcm_drain() returns.


Regards,
Clemens

Re: snd_pcm_wait function

[Trent Piepho]

You do have to fill to a full period before calling drain, or it won't
work in a very useful way.  It only stops when periods elapse.  So if
you have a half full period of audio at the end of the buffer you'll
get garbage when it plays to the end of that period before stopping.

On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Enno Fennema wrote:
>> I want to close the pcm AFTER the sound finished.
>
> Then close it after snd_pcm_drain() has returned.
>
>> The docs say calling drain() puts the pcm in the DRAINING state.
>
> It also waits until the device has drained (unless the device is in
> non-blocking mode).
>
>> When I obtain the state immediately after drain() it is already SETUP.
>> I hoped a state change from DRAINING to SETUP  would be the right time
>> to close the pcm but there appears to be no such state change.
>
> That change happens immediately before snd_pcm_drain() returns.
>
>
> Regards,
> Clemens
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd_pcm_wait function

[Daniel Sanz]

Can I expect that there won't be any pending frames (so no need to
call snd_pcm_drain) if I always use snd_pcm_writei to write multiples
of the period size?

And what if the sound is very short or the period size is big? the
latency of hardware is negligible?

Thanks,

On Mon, Nov 12, 2012 at 9:57 PM, Trent Piepho <tpiepho@gmail.com> wrote:
> You do have to fill to a full period before calling drain, or it won't
> work in a very useful way.  It only stops when periods elapse.  So if
> you have a half full period of audio at the end of the buffer you'll
> get garbage when it plays to the end of that period before stopping.
>
> On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>> Enno Fennema wrote:
>>> I want to close the pcm AFTER the sound finished.
>>
>> Then close it after snd_pcm_drain() has returned.
>>
>>> The docs say calling drain() puts the pcm in the DRAINING state.
>>
>> It also waits until the device has drained (unless the device is in
>> non-blocking mode).
>>
>>> When I obtain the state immediately after drain() it is already SETUP.
>>> I hoped a state change from DRAINING to SETUP  would be the right time
>>> to close the pcm but there appears to be no such state change.
>>
>> That change happens immediately before snd_pcm_drain() returns.
>>
>>
>> Regards,
>> Clemens
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd_pcm_wait function

[Trent Piepho]

snd_pcm_drain() will drain all the pending periods.  In effect, it
rounds up however many frames are left in the buffer to the next whole
period.  There is no way to just drain a partially full period.

If you always wrote full periods, and didn't use non-blocking mode so
that each writei call always wrote everything before returning, then
you shouldn't have a partially filled period at the end of the buffer.

ALSA has the exact buffer pointer value of the app pointer and also
when a period should elapse, and could easily tell you the buffer fill
value mod period size, but I don't think there is any API for that.

On Mon, Nov 12, 2012 at 7:15 PM, Daniel Sanz <daniellsanz2@gmail.com> wrote:
> Can I expect that there won't be any pending frames (so no need to
> call snd_pcm_drain) if I always use snd_pcm_writei to write multiples
> of the period size?
>
> And what if the sound is very short or the period size is big? the
> latency of hardware is negligible?
>
> Thanks,
>
> On Mon, Nov 12, 2012 at 9:57 PM, Trent Piepho <tpiepho@gmail.com> wrote:
>> You do have to fill to a full period before calling drain, or it won't
>> work in a very useful way.  It only stops when periods elapse.  So if
>> you have a half full period of audio at the end of the buffer you'll
>> get garbage when it plays to the end of that period before stopping.
>>
>> On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>> Enno Fennema wrote:
>>>> I want to close the pcm AFTER the sound finished.
>>>
>>> Then close it after snd_pcm_drain() has returned.
>>>
>>>> The docs say calling drain() puts the pcm in the DRAINING state.
>>>
>>> It also waits until the device has drained (unless the device is in
>>> non-blocking mode).
>>>
>>>> When I obtain the state immediately after drain() it is already SETUP.
>>>> I hoped a state change from DRAINING to SETUP  would be the right time
>>>> to close the pcm but there appears to be no such state change.
>>>
>>> That change happens immediately before snd_pcm_drain() returns.
>>>
>>>
>>> Regards,
>>> Clemens
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd_pcm_wait function

[Daniel Sanz]

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
fill a full last period, audio does not play from the beginning to end
unless I call snd_pcm_drain just before closing the stream. I think
there is some concept that I'm missing about how ALSA works, or maybe
my driver/ALSA configuration is broken (I'm using Arch Linux).

Do you have a brief example of playing a short WAV file using ALSA?

On Tue, Nov 13, 2012 at 5:45 AM, Trent Piepho <tpiepho@gmail.com> wrote:
> snd_pcm_drain() will drain all the pending periods.  In effect, it
> rounds up however many frames are left in the buffer to the next whole
> period.  There is no way to just drain a partially full period.
>
> If you always wrote full periods, and didn't use non-blocking mode so
> that each writei call always wrote everything before returning, then
> you shouldn't have a partially filled period at the end of the buffer.
>
> ALSA has the exact buffer pointer value of the app pointer and also
> when a period should elapse, and could easily tell you the buffer fill
> value mod period size, but I don't think there is any API for that.
>
> On Mon, Nov 12, 2012 at 7:15 PM, Daniel Sanz <daniellsanz2@gmail.com> wrote:
>> Can I expect that there won't be any pending frames (so no need to
>> call snd_pcm_drain) if I always use snd_pcm_writei to write multiples
>> of the period size?
>>
>> And what if the sound is very short or the period size is big? the
>> latency of hardware is negligible?
>>
>> Thanks,
>>
>> On Mon, Nov 12, 2012 at 9:57 PM, Trent Piepho <tpiepho@gmail.com> wrote:
>>> You do have to fill to a full period before calling drain, or it won't
>>> work in a very useful way.  It only stops when periods elapse.  So if
>>> you have a half full period of audio at the end of the buffer you'll
>>> get garbage when it plays to the end of that period before stopping.
>>>
>>> On Mon, Nov 12, 2012 at 2:36 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>> Enno Fennema wrote:
>>>>> I want to close the pcm AFTER the sound finished.
>>>>
>>>> Then close it after snd_pcm_drain() has returned.
>>>>
>>>>> The docs say calling drain() puts the pcm in the DRAINING state.
>>>>
>>>> It also waits until the device has drained (unless the device is in
>>>> non-blocking mode).
>>>>
>>>>> When I obtain the state immediately after drain() it is already SETUP.
>>>>> I hoped a state change from DRAINING to SETUP  would be the right time
>>>>> to close the pcm but there appears to be no such state change.
>>>>
>>>> That change happens immediately before snd_pcm_drain() returns.
>>>>
>>>>
>>>> Regards,
>>>> Clemens
>>>> _______________________________________________
>>>> Alsa-devel mailing list
>>>> Alsa-devel@alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd_pcm_wait function (really snd_pcm_draiin)

[Enno Fennema]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

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.
Not draining aand a usleep() for 0.1 sec plays the full time and 
releases the cpm quicker. As you see in attached example I don't bother 
with periods either.

Not exactly your question but I have given up on drainage for my current 
application.

Regards,
Enno Fennema

[-- Attachment #2: drain.c --]
[-- Type: text/x-csrc, Size: 865 bytes --]

#include <alsa/asoundlib.h>
#include <math.h>

int main(int argc, char** argv) {
  int err, i, n;
  snd_pcm_t *handle;
  int16_t buffer[500];

  for( i = 0; i < 500; i++ ) {		// put 500 samples in buffer
    double omega = (double)(i % 50) * 2.0 * M_PI / 50;
    buffer[i] = sin(omega) * 2500;
  }
  snd_pcm_open(&handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
  snd_pcm_set_params(handle, SND_PCM_FORMAT_S16, 
		     SND_PCM_ACCESS_RW_INTERLEAVED, 
		     1, 22000, 0, 50000 );
  snd_pcm_start(handle);

  n = 2200;		
  while( n > 500 ) {
    err = snd_pcm_writei(handle, buffer, 500);
    if( err < 0 )
      printf("Error %d : %s\n", err, snd_strerror(err));
    n -= err;
  }
  err = snd_pcm_writei(handle, buffer, n);

#if 0
  snd_pcm_nonblock(handle, 0);	// ** 1 - nonblock; 0 - Do block
  snd_pcm_drain(handle);
#else
  usleep(100000);
#endif
  return 0;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: snd_pcm_wait function (really snd_pcm_draiin)

[David Henningsson]

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

Re: 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@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