<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 31, 2012 at 5:32 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">
<div class="im"><br>
On Mon, December 31, 2012 6:58 am, Paul Davis wrote:<br>
> On Mon, Dec 31, 2012 at 9:47 AM, Len Ovens <<a href="mailto:len@ovenwerks.net">len@ovenwerks.net</a>> wrote:<br>
><br>
>><br>
>> On Sun, December 30, 2012 7:12 pm, Devin Anderson wrote:<br>
>><br>
>> ><br>
>> > JACK *could* deal with this issue, but:<br>
>> ><br>
>> > 1.) It would be better if the functionality was independent of JACK.<br>
>> > 2.) I don't think the issue is JACK's responsibility.<br>
>><br>
>> Quite honestly, it does not seem to be something that _should_ be done<br>
>> by<br>
>> ALSA either, because properly joining two devices would mean an extra<br>
>> buffer (and latency).<br>
><br>
><br>
> this is not true, if they are clock-synced.<br>
<br>
</div>Well there is sync and sync. It seems the cards are in "sync" in that they<br>
are exactly the same frequency, but not in "sync" phase wise in the<br>
transfer of data. </blockquote><div><br>"startup" of linked PCM devices should take less than a handful of milliseconds. if it doesn't then i suggest that its a driver-specific issue, not an ALSA one. the internal driver design has this in mind. if they are <<1 sample "out of phase" it should not make any difference *if* ALSA waits for the last/slowest device. <span class="HOEnZb"><font color="#888888"><br>

</font></span></div></div><br></div>