<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 30, 2012 at 8:50 PM, Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ck sets the device up (sends sample rate and buffer size) doesn't<br>
the multi device have to send that info to both devices? Wouldn't that<br>
start both at the same time? Making the difference between readiness<br>
within a sample? (I ask because I don't know) When the master restarts, is<br>
there any indication sent to the slave via s/pdif?<br></blockquote><div><br>s/pdif won't carry that information.<br><br>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.<br>
<br>the problem as it been described here, seems more to be:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">><br>
> So, you get a situation where poll() returns because there's data on<br>
> the master device, but then the 'multi' device indicates there's no<br>
> data because it checks all of the devices and returns the minimum<br>
> value for the amount of data available, which JACK thinks is an xrun<br>
> because the ALSA driver's wait function returns 0 when anything less<br>
> than a period's worth of data is available, and a 0 result is<br>
> interpreted as an xrun.  This results in tons and tons of xruns, as<br>
> JACK essentially busy waits until there is actually a period of data<br>
> available on all of the devices that make up the multi device.<br></div></blockquote><div><br>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.<br>
</div></div></div>