From alsa-devel-owner@alsa.jcu.cz  Thu Aug 13 22:14:24 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 WAA28469;
	Thu, 13 Aug 1998 22:13:03 +0200
Received: from obelix.fvdpol.inter.nl.net by altrade.nijmegen.inter.nl.net
	via bd99-1.Breda.NL.net [193.79.246.226] with ESMTP
	id WAA21517 (8.8.8/3.28); Thu, 13 Aug 1998 22:13:01 +0200 (MET DST)
Received: (from frank@localhost) by obelix.fvdpol.inter.nl.net (8.8.7/8.7.3) id WAA21937; Wed, 12 Aug 1998 22:26:00 +0200
From: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
Message-Id: <199808122026.WAA21937@obelix.fvdpol.inter.nl.net>
Subject: Re: Raw and sequenced MIDI........
To: perex@jcu.cz (Jaroslav Kysela)
Date: Wed, 12 Aug 1998 22:25:59 +0200 (MET DST)
Cc: alsa-devel@jcu.cz (alsa)
In-Reply-To: <Pine.LNX.3.95.980810220513.11301C-100000@marvin.jcu.cz> from "Jaroslav Kysela" at Aug 10, 98 10:16:17 pm
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
> 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).

Looks good. In 'real' ALSA sequencer live this can be done with a
conversation as shown below (example only).

Asume a sequencer client driver that implements a MIDI out driver named "midi".
and two file players named "player1" and "player2".


'midi' is loaded & initialised  -> Announcement "a new client [xxx] has attached"
'midi' registers the port       -> Announcement "a new port [xxx] has attached"
...
'player1' is started            -> Announcement "a new client [xxx] has attached"
'player1' opens 'midi's port    -> Request open to 'midi'
'midi' actually opens the device-> Acknowledge (success/fail) to 'player1'
     [port usage count = 1]     -> Announcement "a port [xxx] has be opened"
...
'player2' is started            -> Announcement "a new client [xxx] has attached"
'player2' opens 'midi's port    -> Request open to 'midi'
'midi's port is already open, it
only increments reference count -> Acknowledge (success) to 'player2'
     [port usage count = 2]
...

etc.

when the last client that has opened the 'midi' port quits, the port will be
actually closed, thus releasing the port's resources. The close of this port
will also be announced as a system message.

By using this messaging approach it does not matter if the port driver will
be implemented in kernel space or user space. Both kind of clients have to
abillity to send/receive messages. If an ioctl() like interface would have
been used it would be _required_ to implement drivers in kernel space => not
good, leave the decision to the developer/user.

Anything I overlooked / misunderstood? Please shoot!

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/

