Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Tue Feb 26 2002 - 17:19:10 EET
> >> All OSS and ALSA raw MIDI devices support the same API:
> >> open/read/write/close. There seems to be no need whatsoever to do
> >> anything but use this API. There is no need to write any drivers. Just
> >> deliver the data to them with write(2), and let them do their (best
> >> effort) thing.
> >
> >This is what a lot of applications would actually use. So in the API I'm
> >working on this is provided by using the 'immediate' mode 'path' to
> >a port on an interface.
>
> whats the difference between this and the ALSA sequencer? it has a
> "direct" mode that simply delivers the data to the client without any
> queuing.
Then I don't think this is different. But there are other differences.
> it sounds to me as if your time would be better spent helping to move
> the ALSA sequencer into user space. if not, you'd probably be better
> off using MidiShare, which is an existing user-space MIDI
> sequencer/multiplexer/router, runs on linux/windows/macos and
> others, and does most of what I think you'd want.
The ALSA sequencer does something that I think shouldn't be in the
MIDI API, i.e. the scheduling of events from multiple sources and
not necissarily in timed order. My API would probably provide only
one scheduled path to any port and would require the events to be
sent to it in timed order. This is different from the ALSA sequencer,
which is too high level IMHO
> >The Emagic AMT interfaces can use a technique to allow for simultaneous
> >transmission of data on multiple ports. Since they have not yet been
willing
> >to supply me with the specifications I don't know how it works exactly,
but
>
> i don't believe that its "simultaneous". i'd be willing to bet that
> its "so close together in time, its all within the transmission time
> of a single MIDI byte (or even bit)". you could do this pretty easily
> on existing hardware under linux as long as the h/w FIFO's are empty.
Single byte used to trigger scheduled messages for multiple ports is what
I understand. This can improve timing when messages are known in
advance. This requires that the API enables sending the messages to
the interface early and rawmidi does not support this, at least not in
a device independant way.
> >In order to be able to have full support in the API for multiport
> >interfaces with a special timing protocol (Emagic, Steinberg, not the
> >Midimans I think, they just add some latency, perhaps Protools in the
> >future for their new MIDI interfaces).
>
> again, since the ALSA sequencer is going to have to deal with these at
> some point, it seems more sensible to me to solve this at that level.
The ALSA sequencer is still high level. You could use it on top of a
general API for MIDI I/O that supports early transmission.
> i prefer to focus on an API that has precise timing semantics and not
> think (at the same time) about how it implements it. if we are able to
> get the specs on those devices, perhaps we can use them to provide
> precise timing.
Not without the application (which can be the ALSA sequencer) sending
the messages ahead of time, so not with a rawmidi interface.
> perhaps someone can figure out a way to generate an
> interrupt at the MIDI data rate.
What would that gain us?
> it seems to me that it shouldn't be a
> visible part of the API, which should just accept pre-queued data and
> ensure that it is delivered to the wire as close to the correct time
> as possible. the ALSA sequencer seems to me to do this.
This and more. And since the ALSA sequencer uses rawmidi for i/o it
cannot at this moment support early transmission. If the ALSA sequencer
would be user space and would only support the minimum required
scheduling for use of modern multiport interfaces than it would be
much like what I'm working on. But I see the ALSA sequencer as a
high level service for applications that do not implement the MIDI timing
themselves. I am designing a low level API for MIDI interface access, not
a high level sequencer.
--martijn
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 17:11:16 EET