underrun problems after setting parameters with snd_pcm_set_params()
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 :-)
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
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
participants (2)
-
Kai Vehmanen -
robert rozee