Subject: Re: [linux-audio-dev] introduction & ideas
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Feb 26 2002 - 04:58:29 EET
>> My own approach to this has tended to be to deliver data directly to
>> the device driver (i.e. do not use a "sequencer" layer) at my best
>> approximation to when it should be delivered to the wire, and assume
>> that the device driver and the hardware will work hard to do the best
>> they can.
>>
>> Notions of time are best handled entirely in an application, as far as
>> i can tell. I don't want an external system to try to deliver my stuff
>> "when it is supposed to" unless "when" is "right now". The system's sense
>> of priorities and so forth might be very different to what I want.
>
>...using the driver directly is a problem. Writing support for serial MIDI
>interfaces is, as far as I can tell, unnecissarily difficult. So a library
>is better.
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.
>It would not really need to do scheduling also but this would enable much
>better timing on professional mulitport serial/usb MIDI interfaces, since in
>order to send MIDI messages on all ports at the same time they will have
>to be sent ahead of time.
This is not of any general use. You cannot queue MIDI data in advance
unless you know what it is going to be. This is either impossible
(such as in applications like SoftWerk), or causes "latency" when
doing real-time editing of the MIDI data.
However, I will admit that it works in enough cases to be useful :)
Seriously though: all those interfaces really have over Linux on a
dual CPU system is a timer that runs at exactly the MIDI data
rate. The old GUS cards used to have such a thing, but AFAIK, no other
audio/MIDI interface has ever provided this. If we had such a timer,
we could do *everything* those devices do within the context of the
OS. As is, we are stuck with nearest-multiple timing, which isn't
really quite good enough in a head-to-head competition with those
things.
>For the same reason as mentioned above I can't implement the API on top
>of rawmidi and that is also my problem with the ALSA sequencer (that and
>the fact that it is in the kernel).
which reason? I am not following ...
--p
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 04:51:03 EET