<br><br><div class="gmail_quote">2011/1/29 Saúl Ibarra Corretgé <span dir="ltr"><<a href="mailto:saul@ag-projects.com">saul@ag-projects.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<div class="im"><br>
<br>
On 01/28/2011 10:05 PM, Jeff Pyle wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adrian,<br>
<br>
Trick question or not I was curious about the same thing. Asterisk's<br>
timing issues, for example, are well known in many parts. Yet that seems<br>
to be okay these days in a VM. I have Meetme conferences running in a Xen<br>
domU with no problems.<br>
<br>
It's my limited understanding that how an application references a timer<br>
will dictate its feasibility in a VM.<br>
<br>
So, in this case, think it might work?<br>
<br>
</blockquote>
<br></div>
SylkServer uses PJMEDIA as the media backend, which uses the physical soundcard as a timing source. If there is no soundcard thread based timing is used.<br>
<br>
Rack servers don't usually have a soundcard, so running without a soundcard and running virtual ins kind of the same.<br>
<br>
About Asterisk, the timing issues were resolved long ago and works very well with DAHDI if HPET is enabled. Latest releases support other timing sources: TimerFD and pthreads based timing. AppKonference did the timing and on its own, but it also brought another advantage: the possibility of not to use Zaptel/DAHDI (MeetMe uses DAHDI mixing engine, so it's limited to 8KHz...).<br>
<font color="#888888">
<br>
-- <br>
Saúl Ibarra Corretgé<br>
AG Projects</font><div><div></div><div class="h5"><br>
<br></div></div></blockquote><div>This is getting really interesting, i am interested in your project and looking forward to test things.</div><div>Thank you for your input. </div></div>