Re: [linux-audio-dev] Sequencers & scheduling

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Sequencers & scheduling
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma tammi  10 2000 - 14:26:35 EST


>I have a question for anyone who's designed a sequencer with tempo
>controls:
>
>How do you handle the timing of events in the output?
>
   .
   .
   .

>2) Instead of scheduling events, merge them into a sorted queue of
>events, each of which has a start time (in beats) associated with
>it. At a fixed interval (e.g. once every 0.5 milliseconds?), we
>advance the beat clock by an amount determined by the current tempo,
>and then check the queue to see if the soonest event is supposed to
>happen yet (or if it's already late). If so, pop events off the
>queue and send them to the output stream until we find one that's
>not supposed to happen yet.
   
   .
   .
   .

> DISADVANTAGE: Timing is not so accurate, suffering from
> jitter.

Why ? The jitter is a low as you can get your timebase resolution to
be. If you don't use an audio device, you're limited to the system
clock (20ms for i386), but thats true of in the in-kernel
sequencer(s), at least by default. I don't see how your first scheme
can be any more accurate.

BTW, I've actually done something a little like this in SoftWerk, but
there is no event queue there at all - each sequence just has its own
"time that i should be checked next"; every time we get "interrupted"
by the "clock", we look at each sequence to see if it needs attention,
and if so, we execute a member function that takes the current time as
an argument. That's because SoftWerk sequences work only in the
present, never computing anything ahead except for the next time they
need attention. This interval is called gate time, and its vaguely
related to tempo, but not directly. Timing is limited to the interrupt
frequency, which currently still is based on the system clock
(sigitimer(2)). At some point, I plan to make it use Steve
(steve-what-is-your-last-name?)'s provision of the RTC as an ALSA
timing source.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST