On Sun, Dec 30, 2012 at 8:50 PM, Len Ovens <len(a)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.