From alsa-devel-owner@alsa.jcu.cz  Thu Aug 13 22:41:48 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id WAA30340
	for <alsa-devel@alsa.jcu.cz>; Thu, 13 Aug 1998 22:41:27 +0200
Date: Thu, 13 Aug 1998 22:41:27 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: alsa-devel@alsa.jcu.cz
Subject: Re: Raw and sequenced MIDI.......
Message-ID: <Pine.LNX.3.96.980813224110.865E-100000@entry.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 Wed, 12 Aug 1998, Frank van de Pol wrote:

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

Next idea: Shareable (device can be used by one or more clients) and
exclusive (device can be used by one client only) open. Some application
may requests by this 'don't merge events from others'.

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

I agree, ioctl interface in this case is good for communication with
sequencer, but not for port drivers...

Note for implementation: When application doesn't close used clients,
sequencer must do this when close() on application's event queue occurs.

						Jaroslav

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



