Re: [SoX-users] issue with alsa under-run via sox

[Eric W. <nor...@yh...>]

Praedor Atrebates <pr...@ya...> wrote:
> I have some simple voice changing scripts I've been playing with.
> Originally they worked fine but now, all of a sudden, when I start them
> I get a slew of "WARNING Alsa: under-run" messages.  I'm not sure if I
> now have some sort of alsa problem or if it is a problem arising from
> sox.  Anyone have any ideas?

SoX scales the ALSA buffer size to its own --buffer size.  But since
larger SoX --buffer takes longer to process, it may also slow down the
intervals at which SoX feeds the ALSA device (so you may still get
under-runs).

A fix would be to use the largest ALSA buffer the device allows, but
that also harms latency/reporting.  Things like time/progress output
becomes inaccurate and Ctrl-C does not respond quickly.

Anyways, I've experimented with the following patch locally
despite the above caveats:
-----------------------------------------------------------------------
diff --git a/src/alsa.c b/src/alsa.c
index daf040a..e5e806b 100644
--- a/src/alsa.c
+++ b/src/alsa.c
@@ -145,7 +145,7 @@ static int setup(sox_format_t * ft)
   p->period = range_limit(p->buf_len, min, max) / 8;
   p->buf_len = p->period * 8;
   _(snd_pcm_hw_params_set_period_size_near, (p->pcm, params, &p->period, 0));
-  _(snd_pcm_hw_params_set_buffer_size_near, (p->pcm, params, &p->buf_len));
+  _(snd_pcm_hw_params_set_buffer_size_near, (p->pcm, params, &max));
   if (p->period * 2 > p->buf_len) {
     lsx_fail_errno(ft, SOX_EPERM, "buffer too small");
     goto error;
-----------------------------------------------------------------------

A proper fix would likely require expanding the SoX APIs to:

1) allow reporting of format handler latency
   (PulseAudio and ALSA both have functions to get the amount of audio
    buffered in the kernel/hardware, but the API names escape me at the
    moment)

2) Allow an immediate stop of the handler without draining.
   For ALSA, there should be a way to bypass calling snd_pcm_drain()
   when a user hits Ctrl-C.  PulseAudio should call pa_simple_flush()
   instead of pa_simple_drain() if a user hits Ctrl-C.

Using a recent version of PulseAudio itself may lead to fewer skipping
problems (since it also uses a large-as-possible ALSA device buffer),
but I'm less familiar with PA.