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
