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

31 Dec 2005

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