From alsa-devel-owner@alsa.jcu.cz  Tue Apr 21 11:21:08 1998
Received: from pat.bath.ac.uk (qmailr@pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id LAA22844
	for <alsa-devel@jcu.cz>; Tue, 21 Apr 1998 11:20:50 +0200
Received: (qmail 24716 invoked from network); 21 Apr 1998 09:20:44 -0000
Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.1)
  by pat.bath.ac.uk with SMTP; 21 Apr 1998 09:20:44 -0000
Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa04878;
          21 Apr 98 10:20 BST
Message-ID: <353C64BB.237C@bath.ac.uk>
Date: Tue, 21 Apr 1998 10:19:55 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: Question about sequencer midi
References: <Pine.LNX.3.96.980421090148.8841B-100000@entry.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
> 
> On Sun, 19 Apr 1998, Antonio Larrosa wrote:

[snip]

> > I have made a midi player (kmid) using the OSS api, and found that
> > it is very restricted. When I saw the alsa project I wondered if it
> > would have something that imho is very important: Inserting (not just
> > adding) midi events in the buffer and deleting events that were sent to
> > the buffer but were not played yet.
> 
> I assume that good MIDI interface should have two ways to handle events:
> 
> 1) standard buffered (with using write to device)
> 2) realtime (which pass event directly, before current write event queue)

 Yep.

> > I will explain myself, think of an application that is being playing music
> > by adding events to the midi buffer, now the user moves a slider bar to change
> > the volume. If the application is using the OSS driver, it can only add
> > a volume change event to the buffer, but this event is processed a few seconds
> > after the user moved the slider bar !!. Now, if the application uses the alsa
> > driver, it can insert the volume change event to play NOW, and then the user
> > gets inmediate feedback.
> 
> It's not true. OSS driver can handle events directly, too: look for
> SNDCTL_SEQ_OUTOFBAND ioctl. (Only for illustration, I don't like OSS/Lite
> sequencer for any use).

 But it does not work properly (unless they fixed recently). I have
talked
about this with the rosegardeners and the person who does the jazz
stuff.
SNDCTL_SEQ_OUTOFBAND  screws up notes already beeing played via the
buffer
mechanism.

> 
> > I know that midi support has not been fully implemented yet, but have
> > you thought about what I've told ?, what do you think about it ?
> 
> No MIDI support is implemented at current time, but I'm now working on
> raw-midi interface (like /dev/midi0 with OSS, but more enhanced) and after
> this I'm planning make some proposals (all ideas are welcome) for MIDI
> interface which will use only external devices at first time, but it will
> be extended for use with internal onboard synthesizer, too.
> 
> If we speak about OSS sequencer: My idea for ALSA driver is separate MIDI
> events from synthesizer events to make interfaces more clean. There is two
> types of programs: MIDI players/sequencers and module players or programs
> for audio effects. Comments?


 Long term I think we should be thinking about a complete midi/audio API
to be used by higher level applications. The midi and audio start to
merge
together once you start considering real time synthesis that uses the
D/A
output (/dev/dsp ) as a virtual midi device.

 If you want such a virtual synth to respond to midi in events in real
time
then you start hitting some interesting timing problems. If you are
going to
synthesise the waveforms in the users application you rely on the 
system kernel to give you CPU time when you want it. In the standard
linux
kernel YOU CAN NOT RELY ON GETTING THAT TIME WHEN YOU WANT IT.

 This problem must be addressed at some point. One solution might be to
use
the micro-second system kernel patch that allows you to run your own 
application at a higher priority than the kernel (guaranteed micro
second
resolution yum yum). My own investigations indicate that 20mS is the
best resolution
you can get out of the standard kernel. Worse still any window activity
(paging) can hang up things
for a significant time. 

 What are the other options ?


   all the best Paul.

