On Saturday 31 December 2005 17:10, Paul Davis wrote:
> 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.
Many professional musicians want MIDI capabilities on their PCs because they
already own (or want to have) electronic musical instruments communicating
via MIDI. This means that the computer is another piece of musical equipment
in the musician's studio/network.
The kind of scenario you are painting about low latency applications seems
limited to soft synths listening to sequencing applications. Using MIDI to
this kind of communication between two processes running in the same machine
looks a bit overkill to me. MusE has synth plugins, and Rosegarden has DSSI
synth plugins, without ALSA sequencer being involved here.
> > 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.
Exactly. Please, excuse me my poor English. I mean functionality instead of
problem. Let me reword the sentence: ALSA could be even better if there were
another universal mechanism available for every ALSA application, providing
an easy and consistent way to synchronize a queue with an external MTC
master, without needing to recode the whole process for each application.
I know that Ardour provides slave MTC synchronization, and also does
Rosegarden. Each one uses a different approach, and in the future there will
be many more better or worse implementations.
I like the way Rosegarden solves it, using the ALSA sequencer queue skew
parameter. I guess that we can build another ALSA sequencer client, either a
kernel module or a userspace one, accepting MTC input and translating the MTC
sysex messages received to skew in some queues used also by any other ALSA
clients. Comments?
Regards,
Pedro
Received on Sun Jan 1 00:15:05 2006
This archive was generated by hypermail 2.1.8 : Sun Jan 01 2006 - 00:15:06 EET