On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
On Friday 30 December 2005 17:37, Werner Schweer
wrote:
The ALSA seq api is from ancient time were no
realtime threads were
available in linux. Only a kernel driver could provide usable
midi timing. But with the introduction of RT threads the
ALSA seq api is obsolete IMHO.
I don't agree with this statement. IMHO, a design based on raw MIDI ports used
like simple Unix file descriptors, and every user application implementing
its own event schedule mechanism is the ancient and traditional way, and it
should be considered obsolete now in Linux since we have the advanced
queueing capabilities provided by the ALSA sequencer.
low latency apps don't want queuing they just want routing. this is why
the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the
right idea back when he started this, but i agree with werner's
perspective that the queuing facilities are no longer relevant, at least
not for "music" or "pro-audio" applications.
You guys are talking here about MIDI timing,
considering only the event
scheduling point of view, as if Rosegarden or MusE were simple MIDI players.
Of course, playing beats on time is a required feature. But my bigger concern
about MIDI timing issues is when you are *recording* events. Here is where
ALSA queues, providing accurate timestamps for incoming events, are so good.
better than an RT user space thread? sure. by a few microseconds.
It could be the absolute winner if problems like the
audio synchronization
and slave MTC synchronization were solved likewise.
what problems? JACK demonstrates perfect audio sync in the only sensible
way there is (the same way every other system does it); several JACK
clients have MTC slave capabilities, including ardour, and it has
nothing whatsoever to do with the ALSA sequencer.