Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Tue Feb 26 2002 - 21:15:44 EET
> >> perhaps someone can figure out a way to generate an
> >> interrupt at the MIDI data rate.
> >
> >What would that gain us?
>
> you can buffer data in memory, and deliver it at the precise moment
> that it should be. this is all the new MIDI interfaces are doing -
> they just happen to have a clock with the correct frequency.
In order for events to be transmitted on multiple ports at the same time
they will have to be buffered in the interface. Both Emagic and Steinberg
interfaces do this.
> obviously, if you queue too much data to be delivered all in same
> 1msec, it will back up, but there's no way around that - its a
> function of the wirespeed. this is fundamentally what the scheduler in
> the existing ALSA sequencer does, what SoftWerk does etc. but we don't
> have a clock with the correct frequency.
I don't think a clock is needed for MIDI. An event can start at any time.
There is no clock on a MIDI wire.
The operating system should support accurate scheduling though, at least
1 millisecond clock resolution. With Linux this is 10ms at the moment on
i386 IIRC and that is not acceptable.
> >> 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.
>
> ALSA would like to support these devices. Therefore, you can "expect"
> to see the ALSA rawmidi API extend to provide access to early
> transmission. This would be hidden inside the ALSA sequencer's
> operations for apps that used the sequencer.
I agree. But if extending the ALSA rawmidi API is the right way to achieve
this I'm not sure.
> > 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.
>
> Then why not work on the ALSA rawmidi API itself? Propose some new
> calls that can be used to accomplish this? Then both rawmidi apps and
> sequencer using apps can benefit from it.
I'll first write my API and some programs that use it as a proof of concept.
Then I can see how much it differs from the ALSA API.
> I've said many times before that I think the sequencer should decouple
> its two roles: multiplexing+routing from scheduling. i am resistant to
> adding MIDI support to JACK for example, because in theory it solves
> the exact same problem that the sequencer does with regard to data
> routing. i would much rather see the sequencer be in user space, and
> provide library calls to accomplish data
> delivery/distribution/connectivity. i'd also like to see these be
> independent of scheduling, which i think should provide both a
> callback-based "tick" and the opportunity to pre-queue data and have
> it be delivered "automagically". takashi seems to be in favor of at
> least moving it into user space, and i suspect he could be convinced
> to split the functionality this way.
>
> the problem is that with ALSA now in linux 2.5, making significant
> changes like this to the sequencer API might be trickier. or maybe
> not. linus has always appreciated people ripping code out of the
> kernel :) and i'd like to find a good reason to scare people away from
> the existing sequencer API because of this conflation of scheduling
> with data routing. frank and takashi did a great job improving the old
> OSS sequencer design in many, many ways, but i think they didn't go
> far enough in some important directions.
It'll probably still take me some weeks to get a working version of the
MIDI system I'm building. It'll be GPL'd of course. Then you can take
a look at it and tell me what you think.
--martijn
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 21:08:36 EET