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

[Pedro Lopez-Cabanillas]

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