Subject: Re: [linux-audio-dev] introduction & ideas
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Feb 26 2002 - 18:06:55 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.
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.
>> 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.
> 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'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.
--p
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 17:58:30 EET