From alsa-devel-owner@alsa.jcu.cz  Thu Oct 22 13:52:52 1998
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id NAA00727;
	Thu, 22 Oct 1998 13:51:36 +0200
Date: Thu, 22 Oct 1998 13:51:36 +0200 (CEST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Fred Floberg <emng@geocities.com>
cc: F.K.W.van.de.Pol@inter.nl.net, alsa-devel@jcu.cz
Subject: Re: More ALSA Sequencer stuff
In-Reply-To: <Pine.LNX.3.95.981021122727.519A-100000@cyphyn.219.org>
Message-ID: <Pine.LNX.3.96.981022132918.5326E-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, 21 Oct 1998, Fred Floberg wrote:

> 
> 
> On Wed, 21 Oct 1998 F.K.W.van.de.Pol@inter.nl.net wrote:
> 
> > Fred Floberg wrote:
> > > [Tempo problems with playmidi test program]
> > > This is begining to appear to be a problem in
> > > alsa-driver/test/seq/midifile.c, which was written by Timothy Thompson,
> > > and used in Frank's 'playmidi' test program.
> > 
> > Hmmm, I get good timing with the MIDI files I tried. Tempo changes are also
> > handled. Perhaps you can try if it makes a difference to use tick or
> > real-time timestamps (compile option in playmidi.c).
> 
> I've tried a number of things: Switching from tick timing to real-time
> timing, commenting out a sleep_seq() call in write_ev...(), and even
> looking into the lowlevel code for timing issues. No joy.
> 
> The symptom seems to be like a bottleneck in the output to the midi
> device. i.e. the file begins to play at the correct tempo but soon
> slows down during song play, just as though the computer was overloaded
> in trying to write the midi data to the keyboard. This seems to happen
> just as a number of instruments begin to play. If I wasn't running a
> 300mhz K6-2 here I would be convinced that the computer was getting
> bogged down.

This bug is caused probably by MPU-401 driver and bad hardware (such as SB
AWE 32/64). I wrote before some months ago to this list my problems with
this hardware:

SB AWE 64 MPU-401 part have only 2-byte Tx FIFO buffer. This means that
only two bytes from MIDI queue (if Tx FIFO is empty) can be send to
soundcard. Unfortunately MPU-401 doesn't have Tx interrupt (this means
that we don't know in which time is Tx FIFO buffer empty or not full to
send next data). Current MIDI implementation uses this algorithm:

1) send data to soundcard until Tx fifo is full
2) create new system timer and load to one tick 
   (100Hz on i386, 1024 on alpha)
3) sleep until system timer tick isn't reached
4) goto 1

With this algorithm is MIDI Tx for SB AWE 64 on i386 very very bad -
200 bytes per second (experimental tests shows this value very
correctly)..

Unfortunately ALSA cannot do directly polled mode Tx (routine which
queues MIDI data can be called in interrupt, so we cannot use schedule()
function to do it as for example driver paralel port uses).

I have only one idea how we can solve this situation: Create next thread
which will get Tx data from queue and send them to MPU-401. I don't have
time to done it in near future. MPU-401 is very ugly hardware for
multitasking system, but unfortunately this interface is standard :-((
I welcome any other ideas or code for MPU-401 UART driver....

Other soundcards (non SB) with MPU-401 have bigger Tx FIFO (from 8 to 16
bytes) so problem isn't very big as for SB soundcards.

Soundcards which aren't affected (non MPU-401):

1) all GUS soundcards
2) Ensoniq AudioPCI (ES1370/ES1371)

						Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic



