From alsa-devel-owner@alsa.jcu.cz  Mon Jul 20 13:54:29 1998
Received: from iem.mhsg.ac.at (root@iem.mhsg.ac.at [193.170.129.55])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id NAA15545
	for <alsa-devel@jcu.cz>; Mon, 20 Jul 1998 13:53:57 +0200
Received: from webern (webern [193.170.129.37])
	by iem.mhsg.ac.at (8.8.8/8.8.8/Debian/GNU) with SMTP id NAA00414
	for <@iem.mhsg.ac.at:alsa-devel@jcu.cz>; Mon, 20 Jul 1998 13:53:28 +0200
Received: by webern (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id NAA00595; Mon, 20 Jul 1998 13:55:37 GMT
Date: Mon, 20 Jul 1998 13:55:37 GMT
Message-Id: <199807201355.NAA00595@webern>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Winfried Ritsch <ritsch@iem.mhsg.ac.at>
To: alsa-devel@jcu.cz
Subject: midi-transmit times (was:SoundBlaster IRQ (was:  Re: ALSA Sequencer))
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


Frank van de Pol writes:
[...]
 > Is that REALLY so??? I can hardly imagine... If it's true that hardware is
 > very much broken, and I'm wondering how this is dealt with on all those MS
 > windows boxes. Soundblaster is _the_ standard on the Windows platform.
 > Perhaps there is some 'hidden' feature.
 > 
[...]
It is not broken, but it always worked that way ;-), since normaly in programs
on Windows there are mostly two realistaion, 

a) you dont write data on full MIDI-speed or 
b) you try write one byte with a timout of 0.3ms, so (eg. a loop with
1000 write tries), this will waste CU-Time
c) you take the a free timer interrupt...

so you dont miss the next free time on MIDI-output.

If you really messure MIDI-Output of standard applications on
Soundblaster PCs you will find out it will fill MIDI-troughput
not more than 10%... and if there is a merger afterwards 
the sum of the channels merged must not have more than 100%, 
if you dont want to loose messages...

if you have special software eg.sequencer, there is most the solution
b) and c) to have full MIDI-speed.

Anyway psychoacustics says a jitter or delay lower than 10ms could not
be heard by humans on rythmical events....

on movie there is a rule of synchronisation  2(3) frames audio with video
is good enough (1/25 Hz * 2 = 80 ms) ?-) ... so take it easy ...

But, The point is that the sounddriver-developers should make a try that
scheduling intervall for future linux-distributions becomes either:
 
a) smaller or equal 0.5ms or 
b) configurable for different CPU-speeds and optimations or 
c) automatic optimized on boot up or 
d) (my preference)
RTL-patch becomes standard so that drivers can use this (timer) for
reaction times (i have heard) down to 5us ... could also be used for
soundprocessing or virtual audio devices...

mfg winfried
--- DI Winfried Ritsch - ritsch@iem.mhsg.ac.at ---
 INSTITUT FUER ELEKTRONISCHE MUSIK-
 University of Music and Dramatic Art
 Tel. ++43-316-389-7210, Fax.++43-316-389-7008



