sequencer timing issues

sequencer timing issues

[est]

Paul Barton-Davis discourseth:
>
> SoftWerk's problem is even more acute: because one MIDI track can
> control another's output data (e.g. one track controls the volume for
> another track's NoteOn messages), and because the tracks run at
> different speeds and may not ever be in sync, it is *impossible* to
> use any kernel sequencer for any useful work. why ? because until time
> T arrives, its impossible to compute what should actually be
> sent. this means that you can't queue anything in the kernel
> sequencer: you just have to wait for the "tick" to come around, and
> compute what MIDI data should be sent (if any) on that tick.

Hmm..sounds like you're already paying much of the price of the
hyperseq approach..might as well go all the way. :)

> in SoftWerk's case, because it doesn't process audio data in any way,
> I use sigitimer(2) to give me a periodic async signal every so often
> (typically 20-100ms: its controllable in the UI). i use this to
> measure the passage of time, and compute when a beat/tick is
> happening.  soon, i will use the RTC with select(2), which will be
> more accurate and permit much faster tempos than sigitimer can.

Wouldn't you say that an HZ > 100 kernel is the cleanest solution?

Re RTC: I'm about to post (just to linux-audio-dev) an idea about how
*you* can use it without stopping *my* app from using it. :)

Eric

Re: sequencer timing issues

[Paul Barton-Davis]

  [ why softwerk can't use a kernel sequencer ]

>Hmm..sounds like you're already paying much of the price of the
>hyperseq approach..might as well go all the way. :)

thats the plan, just as soon as i:

      * finish autoconf-izing Quasimodo
      * fix Quasimodo's audio input system
      * finish writing a prototype of my take on the plugin API
      * port the ALSA CS4231 driver to pcm-v2
      * port SoftWerk to Gtk--

etc. etc. :)

>> in SoftWerk's case, because it doesn't process audio data in any way,
>> I use sigitimer(2) to give me a periodic async signal every so often
>> (typically 20-100ms: its controllable in the UI). i use this to
>> measure the passage of time, and compute when a beat/tick is
>> happening.  soon, i will use the RTC with select(2), which will be
>> more accurate and permit much faster tempos than sigitimer can.
>
>Wouldn't you say that an HZ > 100 kernel is the cleanest solution?

its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
to IRQ processing *all the time*. and even then, the system timer is
only accurate to 1ms, which is still not adequate for some envisioned
uses of SoftWerk (though given its use of h/w MIDI ports and the speed
of MIDI communication, its pretty excellent for 99% of them :)

--p