On Sun, Dec 30, 2012 at 8:50 PM, Len Ovens <len@ovenwerks.net> wrote:

ck sets the device up (sends sample rate and buffer size) doesn't
the multi device have to send that info to both devices? Wouldn't that
start both at the same time? Making the difference between readiness
within a sample? (I ask because I don't know) When the master restarts, is
there any indication sent to the slave via s/pdif?

s/pdif won't carry that information.

when i studied the ALSA code for this years ago, it looked to me as though even on a late 1990's CPU, you could still expect both devices to start *within* 1 sample of each other.

the problem as it been described here, seems more to be:

>
> So, you get a situation where poll() returns because there's data on
> the master device, but then the 'multi' device indicates there's no
> data because it checks all of the devices and returns the minimum
> value for the amount of data available, which JACK thinks is an xrun
> because the ALSA driver's wait function returns 0 when anything less
> than a period's worth of data is available, and a 0 result is
> interpreted as an xrun. This results in tons and tons of xruns, as
> JACK essentially busy waits until there is actually a period of data
> available on all of the devices that make up the multi device.

so they can be off by 1 sample (for example) and this can happen. ALSA needs to wait for the slowest/last of the linked devices, not the first. or so it appears.