15 Jan
2006
15 Jan
'06
2:36 p.m.
On Sun, 2006-01-15 at 19:28 +0100, mlang wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
The kernel can work around it for the purposes of its own internal
timekeeping, so that clock_gettime() and gettimeofday() return the
correct results. But the kernel can't do anything if JACK uses rdtsc
directly, as the TSCs remain unsynced, kernel workaround or no.
So the kernel has to be changed to report the correct values when
userspace calls clock_gettime(), but JACK also has to be changed to use
clock_gettime() in place of rdtsc.
Lee
On Sun, 2006-01-15 at 14:23 +0100, mlang wrote:
THis doesn't make sense to me, either the kernel can work around it
properly *OR* we have to patch userland.
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
Yes, the TSC is useless on these machines, but the kernel can work
around it. You need JACK patched to use clock_gettime() for
jack_get_microseconds. On Sunday 15 Jan 2006 11:12, Florian Schmidt
wrote:
> If you want to use alsa_seq's queues to schedule events for delivery
> at a later time, you probably might have a look at rosegarden.
There's a file base/test/seq/generator.c in the Rosegarden source tree
that does basically what was described using the sequencer queue. It
does however schedule in real-time rather than beats (and so does
Rosegarden itself).
http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?…
Pretty intersting, I just ran this and noticed it (the diff between
queue and gettimeofday time) drifts about 70 usecs per second. Is this
normal expected behaviour, or another reason to hate the day I decided to buy
a X2 CPU?
P.S.: ANyone got any hard facts on the TSC SMP issues? 2.6.15
is definitely worse for me than 2.6.14, things that used to work just dont anymore.