Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Mar 14 2002 - 12:34:43 EET
> > > Yeah, I think I actually suggested keeping track of "MIDI bytes
> > > sent since last buffer empty state", in order to estimate the
> > > current latency for a MIDI byte sent to the driver...
> >
> > If you're late you're late.
>
> Yes indeed - but I don't see what that has to do with this.
>
> If you're refering to "buffer empty state", this has nothing to do
> with being late. It's just what happens occasionally whenever you're
> not constantly utilizing the full MIDI bandwidth. The MIDI output
> thread should see this happening in it's estimations, and use it to
> reset it's prediction variables, to avoid drifting out of sync with
> the MIDI interface.
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.
> > 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?
[...]
> > 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. It would have to be application level
anyway though, I don't think this should be in the driver (having
a 'priority' per command).
> [...]
> > > 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.
> > Does Linux allow the clock resolution to be set at
> > run time like QNX?
>
> No.
Bummer.
[...]
> 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. :)
--martijn
This archive was generated by hypermail 2b28 : Thu Mar 14 2002 - 12:24:08 EET