From alsa-devel-owner@alsa.jcu.cz  Thu Oct 29 17:33:54 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id RAA32173
	for <alsa-devel@jcu.cz>; Thu, 29 Oct 1998 17:33:42 +0100
Received: from someip.ppp.op.net (d-bm2-16.ppp.op.net [209.152.194.54]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA27690 for <alsa-devel@jcu.cz>; Thu, 29 Oct 1998 11:33:38 -0500 (EST)
Message-Id: <199810291633.LAA27690@renoir.op.net>
To: alsa-devel@jcu.cz
Subject: ALSA sequencer and synth control (Was Re: ALSA + AWE32)
In-reply-to: Your message of "Thu, 29 Oct 1998 14:26:02 +0100."
             <Pine.LNX.3.96.981029141921.29367D-100000@entry.jcu.cz> 
Date: Thu, 29 Oct 1998 11:32:13 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

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.

The only way (that I can currently see) to get the patch load request
to work at the same time as subsequent MIDI event requests are
processed is to get Linux to timeslice two (or more) tasks so that
both proceed. You can't get the correct behaviour from a single event
queue.

OK, so lets propose now that we have two sequencer kernel-side
clients: one of them handles MIDI event requests and one handles patch
loading. This would work if they ran as different tasks, but my
understanding of Frank's sequencer design is that the it handles
kernel-side clients by making a function call provided by the relevant
client (presumably a device driver). Therefore, unless the sequencer
itself is multithreaded (and what a complex design that will be), the
events still get processed serially, and sound production stops.

Therefore, I (tentatively) claim that the only way to avoid this is to
have two separate tasks making calls into the kernel to (1) send a
MIDI request to the sequencer and (2) send a patch load request
somewhere (the sequencer or something else). The kernel will then time
slice both threads, and progress will be made on both activities.

If there have to be 2 tasks to make this work, then the tasks can
either be part of the same process (such as that abstraction actually
exists in Linux), or they can be distinct processes. In the first
case, we'd have Paul Leonard's wish to be able to do patch loading
etc. via the sequencer, and in the second, you'd have my more modular
approach. 

The key thing to recognize, however, is that there are multiple
interfaces anyway: the sequencer has be able to route messages to
"fast" and "slow" clients separately. It can do this by being
multi-threaded itself, or by having multiple tasks using its
services. Call it what you want, but I consider the "slow" interface
to be equivalent to a "synth control" interface (since virtually all
of the "slow" requests will involve downloading significant chunks of
data, presumably to control the synth), and I therefore don't see how
you can avoid this distinction *at some level*.

BTW, I've thought about parts of this *a lot* and parts of this not
much at all.

--p

