Re: [linux-audio-dev] Audio/Midi system - RT prios..

From: Paul Davis <paul@email-addr-hidden>
Date: Sat Dec 31 2005 - 00:10:44 EET

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.
Received on Sat Dec 31 04:15:05 2005

This archive was generated by hypermail 2.1.8 : Sat Dec 31 2005 - 04:15:05 EET