underrun problems after setting parameters with snd_pcm_set_params()

underrun problems after setting parameters with snd_pcm_set_params()

[robert rozee]

hi,
    i'm having some problems using ALSA to stream simple sounds on one 
particular netbook running EasyOS, a cut-down 64-bit linux distro that is 
rather slow.
 

the problem only occurs with SHORT sound clips. i found that clips longer than 
1111ms played without flaw. clips less that 500ms generally failed to play to 
the end, but there was no error code returned.

clips between 501ms and 1111ms generated the error message: 
"ALSA lib pcm.c:8424:(snd_pcm_recover) underrun occurred".

my buffer size is equivalent to 500ms.

the code essentially does the following:
 
-----------------------------------------------------------------
snd_pcm_open(@handle, "default" , SND_PCM_STREAM_PLAYBACK, 0);
snd_pcm_set_params(handle, SND_PCM_FORMAT_U8,
                           SND_PCM_ACCESS_RW_INTERLEAVED,
                           1,                           // number of channels
                           48000,                       // bitrate (bps)
                           1,                           // resampling on/off
                           min(500000, sample_length)); // latency
while (frames_left_to_write>0)
{
//
// CODE IN HERE TO: refill buffer, and set frames_to_write_now appropriately
//
// send out current buffer content
  frames=snd_pcm_writei(handle, @buffer, frames_to_write_now);
  if frames<0 then frames=snd_pcm_recover(handle, frames, 0);
  if frames<0 then break;
}
-----------------------------------------------------------------
******************************************************************************** 
the problem, as far as i can tell, is with snd_pcm_writei() failing to play the
portion of the sound clip in the buffer, but returning NO error code. the error 
-EFILE is only generated on the attempt to write a SECOND buffer load.

the sound sample i'm using is a 440Hz sine wave tone, amplitude of +/-100, 
centred around 128. ends are feathered in/out, so any short playback is very 
obvious.

after doing a bit of a search on similar problems, i'd like to speculate that 
snd_pcm_set_params() is choosing an inappropriate small period size. for 
low-end computers this is causing the underrun issue. if snd_pcm_set_params() 
is used for configuration, is there any way to change the period size after the 
call? can it be set between opening the handle and setting the other parameters?


cheers,
rob :-)

Re: underrun problems after setting parameters with snd_pcm_set_params()

[Kai Vehmanen]

Hey,


On Tue, 28 Apr 2020, robert rozee wrote:

> the problem only occurs with SHORT sound clips. i found that clips longer than 
> 1111ms played without flaw. clips less that 500ms generally failed to play to 
> the end, but there was no error code returned.

in general, given you have sources available to all the popular apps, it's 
good to check how other apps use the API. I.e. aplay.c may be useful 
simple additional reference for you to see how to use the interfaces.

I think you are missing draining the samples at the end, and then 
your latency is setting is incorrect. I.e.

> snd_pcm_set_params(handle, SND_PCM_FORMAT_U8,
>                            SND_PCM_ACCESS_RW_INTERLEAVED,
>                            1,                           // number of channels
>                            48000,                       // bitrate (bps)
>                            1,                           // resampling on/off
>                            min(500000, sample_length)); // latency

That sample_length does not look, the unit is usecs here. Please try
just putting latency of 500000 (i.e. 0.5sec).

> // send out current buffer content
>   frames=snd_pcm_writei(handle, @buffer, frames_to_write_now);
>   if frames<0 then frames=snd_pcm_recover(handle, frames, 0);
>   if frames<0 then break;
> }

When you have finished writing the audio samples to the ALSA device, you 
need to wait until ALSA has a chance to play all samples out. If you look 
at playback_go() in aplay.c, you'll see:

       snd_pcm_nonblock(handle, 0);
       snd_pcm_drain(handle);
       snd_pcm_nonblock(handle, nonblock);

... at the end. 

Br, Kai

Re: underrun problems after setting parameters with snd_pcm_set_params()

[robert rozee]

   hi Kai,
       well, that's embarrassing! the problem was indeed largely with the
   latency setting.

   the min(500000, sample_length) was to allow for samples of as short as
   50ms.
   i had found that short clips they were not playing at all - but that
   was before i added in
   snd_pcm_drain(handle).

   with latency fixed at 500000 and snd_pcm_drain(handle) at the end,
   everything
   now seems to be working perfectly!

   much appreciate your help   :-)


   cheers,
   rob   :-)


   robert rozee
   p.o. box 25-232
   christchurch, new zealand
   phone: +64 21 123-2603
   email: rozee@mail.com


   Sent: Wednesday, April 29, 2020 at 3:52 AM
   From: "Kai Vehmanen" <kai.vehmanen@linux.intel.com>
   To: "robert rozee" <rozee@mail.com>
   Cc: alsa-devel@alsa-project.org
   Subject: Re: underrun problems after setting parameters with
   snd_pcm_set_params()
   Hey,
   On Tue, 28 Apr 2020, robert rozee wrote:
   > the problem only occurs with SHORT sound clips. i found that clips
   longer than
   > 1111ms played without flaw. clips less that 500ms generally failed to
   play to
   > the end, but there was no error code returned.
   in general, given you have sources available to all the popular apps,
   it's
   good to check how other apps use the API. I.e. aplay.c may be useful
   simple additional reference for you to see how to use the interfaces.
   I think you are missing draining the samples at the end, and then
   your latency is setting is incorrect. I.e.
   > snd_pcm_set_params(handle, SND_PCM_FORMAT_U8,
   > SND_PCM_ACCESS_RW_INTERLEAVED,
   > 1, // number of channels
   > 48000, // bitrate (bps)
   > 1, // resampling on/off
   > min(500000, sample_length)); // latency
   That sample_length does not look, the unit is usecs here. Please try
   just putting latency of 500000 (i.e. 0.5sec).
   > // send out current buffer content
   >   frames=snd_pcm_writei(handle, @buffer, frames_to_write_now);
   >   if frames<0 then frames=snd_pcm_recover(handle, frames, 0);
   >   if frames<0 then break;
   > }
   When you have finished writing the audio samples to the ALSA device,
   you
   need to wait until ALSA has a chance to play all samples out. If you
   look
   at playback_go() in aplay.c, you'll see:
   snd_pcm_nonblock(handle, 0);
   snd_pcm_drain(handle);
   snd_pcm_nonblock(handle, nonblock);
   ... at the end.
   Br, Kai