From alsa-devel-owner@alsa.jcu.cz  Sat Oct 17 19:05:53 1998
Received: from cyphyn.219.org (nwhn-sh9-port195.snet.net [204.60.16.195])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id TAA24510
	for <alsa-devel@jcu.cz>; Sat, 17 Oct 1998 19:05:40 +0200
Received: from localhost (emng@localhost)
          by cyphyn.219.org (8.8.4/8.8.4) with SMTP
	  id NAA09732 for <alsa-devel@jcu.cz>; Sat, 17 Oct 1998 13:08:47 -0400
Date: Sat, 17 Oct 1998 13:08:47 -0400 (EDT)
From: Fred Floberg <emng@geocities.com>
To: alsa-devel@jcu.cz
Subject: More ALSA Sequencer stuff
In-Reply-To: <199810141734.NAA08478@cyphyn.219.org>
Message-ID: <Pine.LNX.3.95.981017121353.9505B-100000@cyphyn.219.org>
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, 14 Oct 1998 I wrote:

> When attempting to insert the sequencer modules from 0.2.0-pre6 (same code
> as found in -pre8, I think)

I've since downloaded the CVS version of ALSA, and for the purposes of
this bug report, the -pre6 code and the CVS code is the same.

> insmod refused to load them with the error:
> 
> snd_seq_dispatch_single_event: undefined symbol (that's going from memory)
> 
> After searching through the sequencer code I was able to track down where
> the error was coming from.
> 
> In ..../kernel/seq/seq_queue.c line 317, a call to
> "snd_seq_dispatch_single_event(new_cell);" is being made. Since that
> function is not in the list of exported symbols it generates the error.
> Changing the line to "snd_seq_dispatch_event(new_cell);", which is
> exported, and which calls snd_seq_dispatch_single_event() itself,
> allows the modules to load and function.

After more code reading and testing it appears that the fix above is
in fact a viable one.

To summerize:

Line 317 of alsa-driver/kernel/seq/seq_queue.c can be changed from

     snd_seq_dispatch_single_event(new_cell);

to

     snd_seq_dispatch_event(new_cell);

in order to get the modules to load and run properly.

> Also, after getting the sequencer modules to load, I ran usertest2
> and playmidi (from the test utils) with some SMF Type 0 files. It
> sounds as though the tempo was slowed down to 1/4 or less of the
> original speed with some files. Other files seemed to run at closer
> to their real tempo but still not quite.

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.

Rather than trying to debug that library I'm going to attempt to port
Nathan Laredo's playmidi-2.3 package over to using ALSA's Sequencer. I
know this package to work very well, and it'll be nice to have a full
featured midi file player (Nathan's playmidi supports SMF Type 0 and 1
files, multiple UI's, etc.) for ALSA.

This will be a good way for me to become more familiar with ALSA's
Sequencer code also.

I'll post an update when I've made some headway with it.
 
> Reading from the MIDI port using usertest1 does not work at all.
 
After more experimenting I've gotten the Sequencer to read from the
MIDI port, using alsa-driver/test/seq/kernel-client_midi.c and usertest3.c



Fred

(BTW, I'm using Linux kernel version 2.0.35 and libc.so.5.4.46. Could
this be problematic?)


