From alsa-devel-owner@alsa.jcu.cz  Mon Aug 10 22:16:28 1998
Received: from localhost (perex@localhost)
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id WAA13943;
	Mon, 10 Aug 1998 22:16:17 +0200
Date: Mon, 10 Aug 1998 22:16:17 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Raw and sequenced MIDI........
In-Reply-To: <199808101953.VAA05290@obelix.fvdpol.inter.nl.net>
Message-ID: <Pine.LNX.3.95.980810220513.11301C-100000@marvin.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 Mon, 10 Aug 1998, Frank van de Pol wrote:

> 
> 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.

Not good..

> 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)

Interresant, but I didn't preffer this...

> 
> 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.

I don't like this. A little bit confusing for end user.

> 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.

Yes, this is good idea. This should be implemented after sequencer core
will be done.

What about this:

Sequencer will know about 4 basic client events:

ATTACH - new client is attached to sequencer
DETACH - client need to be detached from sequencer

OPEN - client will be open (ready to process events)
     - this event is necessary for example for GUS soundcards - DMA needs
       to be allocated for transfers between onboard RAM and system memory,
       persistent open isn't very good
CLOSE - client will be closed (resource free)

OPEN and CLOSE events must be acked back to client which requests this
operation (success or failure)...

Above events solves trouble with rawmidi and others (resource allocation
for example).

Ideas?

					Jaroslav

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


