[Jack-Devel] ALSA PCM multi plugin and xruns

Hello,

I recently bought two Echo Layla 3G devices with the intention of
using ALSA's multi plugin to merge the devices into one device that
JACK could use.  Unfortunately, I find that sometimes, JACK starts
spitting out lots and lots of xruns, even though the audio doesn't
have pops, clicks, etc.

I decided to download the JACK 1 source and attempt to find the
problem.  I placed some additional `jack_error` calls in
`alsa_client.c`.

When the xruns start to happen, the following messages get printed to
the console:

    Available: 0, Frames/Cycle: 256, Capture Available: 0, Playback Available: 0
    detected xrun and restarted
    Available: 0, Frames/Cycle: 256, Capture Available: 0, Playback Available: 0
    detected xrun and restarted
    Available: 0, Frames/Cycle: 256, Capture Available: 0, Playback Available: 0
    detected xrun and restarted
    ... [repeat for a while]

... followed eventually by:

    Recovered - Available: 288, Capture Available: 288, Playback Available: 288
    Available: 32, Frames/Cycle: 256, Capture Available: 32, Playback
Available: 32
    detected xrun and restarted
    Available: 32, Frames/Cycle: 256, Capture Available: 32, Playback
Available: 32
    detected xrun and restarted
    Available: 32, Frames/Cycle: 256, Capture Available: 32, Playback
Available: 32
    detected xrun and restarted
    ... [repeat for a while]

These messages are generated in `alsa_driver_wait`, and seem to
indicate that `snd_pcm_avail_update` is returning a value that's less
than the buffer size.

At the end of `alsa_driver_wait`, the following expression is returned:

    return avail - (avail % driver->frames_per_cycle);

... which will evaluate to 0 any time that avail is less than
driver->frames_per_cycle.

The caller, `alsa_driver_run_cycle`, assumes a 0 return value means
that an xrun was detected and the driver was restarted, which I
believe is not correct in this scenario.

IIUC, the 'xruns' are generated because there *is* data available to
be read, but there *isn't* enough data, which means 0 is returned,
which incorrectly indicates that an xrun happened.  The exception is
when both `capture_avail` and `playback_avail` are both set to 0.
Perhaps userspace hasn't been told about new samples in the kernel
ringbuffer.

I don't know whether this is a bug in the ALSA multi plugin or in
JACK.  I assume the problem is the multi plugin, as
`snd_pcm_hw_params_set_period_size` is called to constrain the period
size to one value, but I don't have enough of an understand of ALSA to
know for sure.  I'm hoping that someone on this list with a better
understanding of ALSA magic will be able to answer that question for
me.

Thanks,

-- 
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/

1354966732.17248_0.ltw:2, <CAG7zqTqgcv2QFR_Mfs9o8ZWkqaDbkVcOPkeuRFvPMvysYvD5YA at mail dot gmail dot com>