[alsa-devel] Re: RT timing / priorities etc. : Was: ALSA and MIDI-Share ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [alsa-devel] Re: RT timing / priorities etc. : Was: ALSA and MIDI-Share ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke syys   01 1999 - 12:41:03 EDT


On Wed, 01 Sep 1999, Stephane Letz wrote:
> >>Actually these 3ms seems a form of "hard realtime",
> >I was not able to generate peaks bigger than 2.9ms ,
> >and I tried to many things simultaneously like
> >ripping an audio CD from a 32x Plextor drive + running bonnie,
> >running 20 instances of xsnow (poor X server :-) ),
> >+ running a kernel compile.
> >Ok my poor PII400 gets very slow, but the latencytest diagrams
> >don't show any peaks bigger than 2.9ms.
> >
> >Consider that 99.8 - 99.9% of time the latency stays in the nominal
> >range +/-500usecs under high load, that means a MIDI sequencer
> >implemented entirely in userspace is able to provide excellent MIDI timing
> > IMHO. (Correct me please if I am wrong).
> >
>
> If this low latency can be achieved, then the design that was used in
> MidiShare (user code callback form the kernel for real-time midi event
> handling and for user task) can probably be implemented.
> And the possibility to have several user Midi clients receiving and sending
> Midi events in real-time start to be very interesting!
>
> Stephane Letz

Yes, in the case of MIDI the more important factor is low "latency-jitter" than
absolute latency.
I want to point out that the 2.9ms peak was absolute latency,
the nominal latency in my benchmark was 1.45ms , this means that the maximum
jitter was +/-1.45ms . But as said before very sporadic (0.1% of cases).
The fact that the probability that there is a MIDI event exact at this
latency-peak is VERY low, let's you assume that you get pratically always
only +/-500usec jitter, and even David likes this, (even if the is used to teal
with only double digit usecs :-) )

Question: I don't think that Win95 is able to provide good timing for
Midishare except using dirty tricks like IRQ programming etc.
I think your (userspace) timing (under Wind95) could degrade quite a bit when
doing many other things (disk i/o etc.)

I just went on your Midishare Win95 benchmarks,
http://www.grame.fr/MidiShare/MShare32/BenchsWin95.html

and saw that you got around 4500 messages/sec on a P100 (thread to thread),
and for your MIDI data flow model:

input appl --> Transformator -> output appl

you got 596 usecs for the message traveling from input -> transformator -> ouput
= about 1677msgs/sec

I tested this using a msgsnd/msgrcv() on Linux on my PII400 box.

result ?

42000 messages/sec !! ( 42 times faster than your P100 on Win95)
Divide this number by 4 or 5 to match your P100, and you will get 8000-10000
messages/sec

nice huh ? :-)

Of course your timings are on an * IDLE* Win95 box.
here the snippet from your document

-- 
"In order to control how the processes in charge of the measures can be
preempted, only the system essential processes are running." 
--

I think stressing the Win95 box, with heavy disk I/O etc .. will produce nice *UNACCEPTABLE* peaks in order of tenths of msecs, = bad timing.

Still not convinced that Linux is a good OS for doing audio/MIDI ? :-)

regards, Benno. ------ To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send message 'unsubscribe' in the body of message to <alsa-devel-request_AT_alsa-project.org>. BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST