From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 18:28:18 1998
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id SAA03631;
	Thu, 29 Oct 1998 18:28:12 +0100
Date: Thu, 29 Oct 1998 18:28:12 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Paul Barton-Davis <pbd@op.net>
cc: alsa-devel@jcu.cz
Subject: Re: ALSA sequencer and synth control (Was Re: ALSA + AWE32)
In-Reply-To: <199810291633.LAA27690@renoir.op.net>
Message-ID: <Pine.LNX.3.96.981029181346.29903A-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 Thu, 29 Oct 1998, Paul Barton-Davis wrote:

> I wrote:
> >> I would like to encourage Jaroslav to adopt something like the
> >> /dev/synth* interface, which is intended to be used for
> >> hardware-specific raw access to a soundcard's synthesizer devices, and
> >> can be open concurrently with any access via real or simulated MIDI
> >> devices. Its not meant to be an abstraction: the operations you can
> >> perform via this interface are 100% completely dependent on the
> >> hardware on the "other side".
> 
> Jaroslav said:
> 
> >I think that better way is doing all these communication with lowlevel
> >code over sequencer events. Don't remember, that /dev/sndseq can be open
> >many times (not as /dev/sequencer or /dev/music!!!). Sequencer client
> >should be opened in exclusive or nonexlusive mode, too...
> 
> Well, this is a relief, but ...
> 
> >Thus you can create user space sequencer client which will manage
> >instrument loading etc... We don't need any other interface for this
> >purpose...
> 
> Well, so you claim. But lets think about this:
> 
>       * a MIDI sequencer generating events roughly every 20msec.
>       * a patch load request that will take 1-5 secs to complete
> 
> So, you route them both to the same device via /dev/sndseq, and what
> happens ? 
> 
> First assume that there is a single driver acting as the sequencer
> client, and that it takes requests in serial order.  All sound
> production will stop while the patch load takes place. Not very nice.

No, this situation should never occur. Maybe you are missing something
from new sequencer concept:

1) There is priority QUEUE for real-time events.
2) Priority QUEUE should be bypassed with events without timestamp which
   can be sent directly to the client.
3) Each client have own output FIFO.

In your example will be reached this situation:

The sequencer will fill output FIFO for instrument manager client
(probably user client - application). If FIFO is full, request event will
be simply lost (last or first - this depends on implementation). The user
client will get events with instrument requests and put instrument data
back to sequencer which will use only router to deliver these data
immediately to the kernel client (this is still instrument manager task,
so other tasks willn't be touched if downloading takes very much time).

Maybe Frank should give us more light about this problem...

							Jaroslav

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


