From alsa-devel-owner@alsa.jcu.cz  Wed Oct 14 11:00:38 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 KAA17892;
	Wed, 14 Oct 1998 10:56:45 +0200
Date: Wed, 14 Oct 1998 10:56:44 +0200 (CEST)
From: Jaroslav Kysela <perex@jcu.cz>
To: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: [linux-audio-dev] What to do ??? (fwd)
In-Reply-To: <3624641B.773C@bath.ac.uk>
Message-ID: <Pine.LNX.3.96.981014104804.28026F-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, 14 Oct 1998, P.J.Leonard wrote:

> Frank van de Pol wrote:
> > 
> > P.J.Leonard wrote:
> > >
> > > [snip]
> > >
> > > >    MIDI oriented applications (could also be MOD players): What is needed
> > > >    in the ALSA Sequencer API to let your application work with the new
> > > >    sequencer architecture?
> > >
> > >  An AWE32 driver ? (If I had the time I would do it myself)
> > >
> > 
> > This AWE32 driver is a piece of software (sequencer client) that makes use
> > of the API. To rephrase my question: What needs to be added/changed to the
> > sequencer API to allow someone to implement this AWE32[1] driver.
> > 
> > [1] replace with any other soundcard we need drivers for.
> 
> 
>  Your question was phrased OK the first time I was just a bit lazy
> reading :-)
> 
>  I have not looked at your code recently (too many things I would like
> to do
> and too little time). But I would be very interested in discussing what
> would
> be involved.
> 
>  The AWE driver written by takashi would be a good start. I believe
> this plugs into the OSS stuff using the following interface.
> [I think synth_operations is defined in soundcard.h]
> 
>  static struct synth_operations awe_operations =
> {
> #ifdef AWE_OSS38
> 	"EMU8K",
> #endif
> 	&awe_info,
> 	0,
> 	SYNTH_TYPE_SAMPLE,
> 	SAMPLE_TYPE_AWE32,
> 	awe_open,
> 	awe_close,
> 	awe_ioctl,
> 	awe_kill_note,
> 	awe_start_note,
> 	awe_set_instr_2,
> 	awe_reset,
> 	awe_hw_control,
> 	awe_load_patch,
> 	awe_aftertouch,
> 	awe_controller,
> 	awe_panning,
> 	awe_volume_method,
> #ifndef AWE_NO_PATCHMGR
> 	awe_patchmgr,
> #endif
> 	awe_bender,
> 	awe_alloc,
> 	awe_setup_voice
> };
> 
> 
>  This interface allows loading patches / playing notes / allocating
> voices . As far
> as I can tell the OSS stuff is just a wrapper for these calls (OK it
> adds a bit of timing
> stuff but your design takes care of that). 
> 
>  Midi events would call the relavent functions in the above structure.
> You would also
> need to be able to forward the IOCTL calls. 

OK. I don't like OSS plug-in interface very much, but it maybe used as
temporary hack until ALSA driver willn't be available. I think that all
playback clients must be able receive events from ALSA sequencer kernel.
We must at first design ALSA events and someone (I don't) may write ALSA
event <-> OSS plug-in converter if it's possible (maybe we reach some
major problem with OSS synth plug-in interface which willn't allow it).

I willn't accept encapsulation of OSS events to ALSA events, too. (Maybe
only at kernel level for OSS sequencer emulation - if someone writes it.)
This is very bad thing...

							Jaroslav

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




