From alsa-devel-owner@alsa.jcu.cz  Mon Aug 10 21:58:30 1998
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id VAA12840
	for <alsa-devel@jcu.cz>; Mon, 10 Aug 1998 21:58:05 +0200
Received: from obelix.fvdpol.inter.nl.net by altrade.nijmegen.inter.nl.net
	via bd99-18.Breda.NL.net [193.79.246.243] with ESMTP for <alsa-devel@jcu.cz>
	id VAA13742 (8.8.8/3.28); Mon, 10 Aug 1998 21:58:02 +0200 (MET DST)
Received: (from frank@localhost) by obelix.fvdpol.inter.nl.net (8.8.7/8.7.3) id VAA05290; Mon, 10 Aug 1998 21:53:05 +0200
From: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
Message-Id: <199808101953.VAA05290@obelix.fvdpol.inter.nl.net>
Subject: Raw and sequenced MIDI........
To: alsa-devel@jcu.cz (Jaroslav Kysela), alsa-devel@jcu.cz (alsa)
Date: Mon, 10 Aug 1998 21:53:05 +0200 (MET DST)
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


Hi Jaroslav, 

here's some brain teaser:

If we have raw and sequenced MIDI.... who gets/owns the MIDI port????

Devices that have a MIDI port currently only have a device for RAW MIDI, the
/dev/sndmidi00 etc. devices. 

With the sequenced MIDI interface, using ALSA sequencer I now have a kernel
module open the MIDI device using the kernel API snd_midi_open() calls. If
the sequenced MIDI is attached, RAW device is in use, and /dev/sndmidi00 is
not accessible anymore. :-(

Some thoughts:

1) The current situation where sequenced MIDI uses the raw device, and thus
   blocking the /dev/sndmidi00 is conceptually right, but makes it
   impossible to use applications that want raw access.

2) Perhaps we can allow concurrent access by the sequenced MIDI driver and
   the /dev/sndmidi00 device. Simple byte merging could result in illegal
   MIDI sequences, so real MIDI merger would be needed to do it 'right'. 
   Handling of MIDI input might get messy because of we need to handle more
   than one buffer. (yuck)

3) Other, possibly simpler way to handle this problem is to have the
   sequenced MIDI interface open the MIDI device first (at card
   initialisation?). Whenever some application wants to open the
   /dev/sndmidixx device the sequenced MIDI driver gets notified to release
   the port. This driver does so, and the MIDI port 'vanishes' from the
   sequencer system. The open call to /dev/sndmidixx will give to port to
   the application. Once it is closed, control is given back to the
   sequencer. In short: sequenced normaly 'owns' the MIDI port, but can be
   overruled when the raw device is opened.

4) Add a 'virtual midi port' to the ALSA sequencer, simply a character
   device that allows any application to send aribtrary (but legal) MIDI
   bytes into the sequencer. This data can be automaticly be forwarded to
   the actual MIDI output (MIDI thru function!). A 'side effect' is that
   when send to a hardware MIDI output it does proper MIDI merging, allows
   those MIDI out applications to access onboard synths (such as
   OPL/AWE/GUS), and allows to record this data into a sequencer
   application. This device could be named /dev/sndvmidi00 etc.

I think that option 3 is good enough. Only few applications exists that do
all processing and scheduling in user mode. Their existence is probably a
result of the OSS limitations :-). By adding option 4 in a later stadium all
applications will be pleased...

Of course there are many more options. What do you think about this stuff?

Cheers,
Frank.


+---- --- -- -  -   -    - 
|Frank van de Pol                  -o)
|F.K.W.van.de.Pol@inter.NL.net     /\\
|                                 _\_v
|Linux - Why use Windows, since there is a door?
|
|ALSA Sequencer: http://www.inter.nl.net/users/F.K.W.van.de.Pol/alsa/

