Subject: Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Aug 21 2002 - 04:10:35 EEST
[...]
> Within ALSA we have two priority queues, one for tick (bar,beat) scheduled
> events, and one for clock (ns) scheduled events.
As MIDI uses MIDI tick messages for time based sync and MIDI clock messages
for tempo based sync I kind of feel the ALSA sequencer naming is a little
confusing :)
> In case of immediate
> scheduling the priority queue is bypassed and the event submitted in the
> receiver's fifo (which would be your immediate queue).
>
> Due to potential blocking at the receivers you'll need a fifo for every
> destination.
Correct, that's what I've been calling queues.
> Reason for having 2 priority queues with different reference is to cope
with
> tempo/signature changes while remaining in sync. The clock and tick
priority
> queues are in fact parallel in ALSA.
I don't want to support tempo (MIDI clock) scheduling in my MIDI API. This
could be better handled in the application itself. Also, when slaved to MIDI
clock
it is no longer possible to send messages ahead of time, and not supporting
this
in the API makes that clear to the application programmer.
> Since especially for soft synths (but also for some -undocumented!- USB
midi
> interfaces, like Emagic AMT)
Yes, I've repeatedly asked Emagic for documentation on their AMT protocol
without success. :(
> the events need to be scheduled ahead (sort of
> a pre-delay, say 10ms or more) to let the device/softsynth handle the
micro
> scheduling, it would seem a good idea to handle this at the clock based
> queue. Since variable predelay in ms would be not quite friendly to the
tick
> based queue (different units), it might make sense to have the tick based
> queue send events into the clock based queue instead of immediate
delivery).
I'd rather see MIDI clock sync handled in the application. This also keeps
the
API cleaner.
[...]
> A good reason for applications to use (UST/ALSA) scheduling instead of
> taking care of micro scheduling itself and using rawmidi interfaces is
> better support for softsynths to trigger at the right spot in the buffer,
> and for the upcoming smart (eg. USB) midi devices.
Or even MWPP.
[...]
> You can't overcome the limits of the MIDI physical line if that's your
> target transport. However when sending events to soft- or onboard synths
> these limits are different (typically less of an issue).
>
> When using events instead of midi bytes the merging is a no brainer
I was planning on doing that, but even then there are issues with for
example
(N)RPNs.
> leaves room for events not defined in midi spec).
...I'm not sure that is a good idea. What kind of events?
--martijn
This archive was generated by hypermail 2b28 : Wed Aug 21 2002 - 03:14:45 EEST