Re: [Jack-Devel] ALSA PCM multi plugin and xruns

On Sat, Dec 8, 2012 at 4:51 PM, Devin Anderson
<[hidden]> wrote:

> I added some errors messages to the multi plugin in alsa-lib, and have
> found that:
>
> 1.) Both of the Layla 3Gs have the same amount of frames available
> regardless of whether the xrun onslaught is happening.  So, when 32 is
> reported back as the amount of frames available, both of the devices
> have 32 frames available, despite the period size being 256.

I was wrong about this too.  It appears that one of two scenarios happens:

1.) The master device has (period_size + 32) frames available, and the
other has 0 frames available.
2.) The master device has (period_size + 32) frames available, and the
other has 32 frames available.

So, it sure *looks* like an xrun, but it's not currently being handled
in `alsa_driver_wait` the same way that a detected xrun is handled.

I tried adding the following code just before the last return
statement in `alsa_driver_wait`:

	/* if the number of available frames is less than the expected frame
	   count, then handle this as a buffer underrun */

	if (avail < driver->frames_per_cycle) {
		*status = alsa_driver_xrun_recovery (driver, delayed_usecs);
		return 0;
	}

... and the situation improved considerably.  The onslaught of xruns
is now limited to a few at most.

@Paul, Torben, etc.: I'm not convinced that this is the best or
correct way to solve the problem, or if this will introduce problems
in other setups.  I think you'd know better than me.  If this is an
acceptable fix, I'll submit a patch.  Let me know.

Thanks,

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

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

1355034800.2308_0.ltw:2, <CAG7zqTrAkz0mG-y46u0iXNGqkpGByvg2DQ2ziQ4Jm=kR5wdVBw at mail dot gmail dot com>