>>> The only difference non-jack would make is you need some function to<br>
>>> tell you roughly what audio time it is you can call from another thread.<br>
>><br>
>> Does one use the system clock for that?<br>
> I think frame time (a frame of samples) is meant here  ? That time is<br>
> delivered in the jackd process callback.<br>
><br>
>> Is it accurate enough?<br>
> Depends on the system clock used, I presume.<br>
> For best accuracy, you have to configure your kernel to support HPET<br>
> (high precision event) timers<br>
> and make ALSA use it as default.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">the clock used for the system clock is less important than using a DLL<br>
to "link" the audio clock and the system clock. this enables you to<br>
answer the question "if its time T on clock1, what time is it on<br>
clock2?"<br>
<br>
fons wrote the canonical paper on this for a Linux Audio conference a<br>
few years ago, and JACK contains a DLL for this purpose<br>
(jack_get_microseconds() will return a prediction of the current time<br>
according to the audio clock, based on the system clock and the DLL.<br></blockquote><div><br></div><div>thanks, it's sounding increasing like I should be using jack for the time being. </div><div><br></div><div>Iain</div>
<div><br></div>