Re: [linux-audio-dev] A sequencer example

On Sun, 2006-01-15 at 19:28 +0100, mlang wrote:
> Lee Revell <rlrevell@email-addr-hidden-job.com> writes:
>
> > On Sun, 2006-01-15 at 14:23 +0100, mlang wrote:
> >> Chris Cannam <cannam@email-addr-hidden-day-breakfast.com> writes:
> >>
> >> > 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?view=markup
> >>
> >> 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.
> >>
> >
> > 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.
>
> THis doesn't make sense to me, either the kernel can work around it
> properly *OR* we have to patch userland.
>

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
Received on Mon Jan 16 00:15:05 2006