Subject: Re: [linux-audio-dev] introduction & ideas
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 15 2002 - 12:02:04 EET
On Thursday 14 March 2002 11.34, Martijn Sipkema wrote:
[...]
> What I meant was that if you need to send a MIDI command *now*
> and you know there are still commands pending, you are not going
> to be able to send it *now* and for the application this knowledge
> might not be all that usefull.
There's nothing much you can do about that within the limits of the
MIDI protocol anyway. Comparing with audio again, a buffered MIDI
setup simply doesn't have a notion of affecting the output *now*.
The idea is that "now" in the application, provided it wasn't
scheduled late, is effectively a fixed amount of time *before* "now"
on the outputs - which means that *when* the application is scheduled
late, no harm is done, as the latency will be the same.
> > > Well, 1ms jitter would still be quite good enough for MIDI I
> > > think.
> >
> > Yes. (If people even consider using Windows for serious MIDI
> > work, it has to be "acceptable", at least...)
> >
> > But then you'd have a ~1 kHz timer firing off IRQs all the time
> > anyway - so why not just sleep on the RTC?
> >
> > BTW, is it possible to read N bytes from the RTC device, to say
> > "Please skip N cycles before waking me up"...?
> >
> > Another idea: How about sharing the RTC through multi-open? I
> > would assume this has been considered and rejected because only
> > *some* features can be shared. However, the point is that with
> > multimedia applications requiring higher frequency "clocks" than
> > HZ, simply being able to get a "heartbeat" from the RTC device
> > would be sufficient. The RTC would run at the highest rate
> > requested by anyone using the device, and the driver would keep
> > track of when to wake up which sleeper.
> >
> > Of course, I could just read the code (more carefully than last
> > time) and see if I can figure something out - I just want to know
> > if anyone knows if there's any point in even considering it.
>
> What is the advantage of using RTC over POSIX clocks?
The RTC is normally unused by the OS, and doesn't require per-IRQ
reprogramming through the remains of an encient bus that stalls the
CPU for a few hundred cycles per access.
> [...]
>
> > > Just don't send too much data over a single MIDI wire.
> >
> > Of course - but why making it worse than it is by not utilizing
> > the full MIDI "resolution"?
>
> Because it is not easy to do.
Well, doing things Right rarely is... ;-)
> It would have to be application level
> anyway though, I don't think this should be in the driver (having
> a 'priority' per command).
Yeah. The driver should only have the ability to output events the
way the application intends - just like an audio interface simply
outputs samples in the order received, at the specified rate.
> > [...]
> >
> > > > You don't expect the kernel guys to sacrifice overall
> > > > throughput for near RTL/RTIA class scheduling accuracy, do
> > > > you? :-)
> > >
> > > Hmm.. Then they could maybe make it optional, at run time (or
> > > compile time).
> >
> > It would have to be compile time - but it probably won't happen,
> > as it would require that practically *everything* is fully
> > preemptible. Such an environment is *not* a fun place to hack
> > drivers in. And of course, it's very different from the current
> > environment.
>
> Well, the kernel will have to become fully preemtible anyway, and
> this may not make writing good drivers easier, but then again
> driver writing is not for everyone since you can easily mess up the
> system performance in a driver. There should be rules on how long a
> driver may hold certain locks or disable interrupts/spinlock.
Yeah... But you know, there are still kernel hackers that couldn't
care less about real time. Then again, now they'll get yelled at for
breaking scalability to high end servers! *hehe*
> > > Does Linux allow the clock resolution to be set at
> > > run time like QNX?
> >
> > No.
>
> Bummer.
If you have KURT style one-shot timer mode, just leaving the timer at
a sufficiently high periodic rate shouldn't be too complicated, I
guess...
> [...]
>
> > Yes, but there still seems to be *lots* of work to do before we
> > can even have 2.2.10-lowlatency class real time on a mainstream
> > kernel.
>
> I'll wait. :)
No, go hack some cool stuff instead! ;-) 2.2.10-lowlatency + RTC
should do for now, if you need to test with rock solid scheduling.
Actually, the newer solutions should work as well, as long as you
don't need to stress the system while running your application. (That
is, audio/MIDI would be an issue...)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
This archive was generated by hypermail 2b28 : Fri Mar 15 2002 - 11:54:13 EET