From alsa-devel-owner@alsa.jcu.cz  Tue Jan 19 11:53:01 1999
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 LAA03046;
	Tue, 19 Jan 1999 11:52:11 +0100
Date: Tue, 19 Jan 1999 11:52:11 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: George David Morrison <gdm@gedamo.demon.co.uk>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Suggestions
In-Reply-To: <369E31E2.BA06DB59@gedamo.demon.co.uk>
Message-ID: <Pine.LNX.3.96.990119102034.25743O-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, 14 Jan 1999, George David Morrison wrote:

> Jaroslav Kysela wrote:
> > 
> > > Synth specific parameters:
> > >   Rather than have a different interface for each type of onboard synth,
> > > wouldn't it be possible to present all synths as a MIDI device and pass
> > > synth specific parameters via sysex messages?
> >
> > Looks very much complicated for me. Better is create some private events
> > for onboard synthesizers. I'm still thinking about sample/instrument
> > download interface (more will come in next mail from me).
> 
> It would be hard to implement from the driver side but it would make
> applications easier to write as they would only have one kind of
> interface to deal with.

All these functions should be available in the alsa-lib library, thus most
of applications will probably call only a 'download program number'
function and alsa-lib will detect what instrument and how it should be
downloaded to the onboard synthesizer.

SYSEX doesn't seems as way for me. It is limited (I think that maximum
length should be about 256 bytes) and we must escape end char. Please,
consider that we must transfer instruments which should have over 1MByte!!

I'm thinking about some special events which should point to shared memory
(to avoid trouble with kernel-side memory allocation). In shared memory
should be stored whole instrument (headers & data) and lowlevel wavetable
driver should reject bad instrument and accept good instrument.

> > > Jaroslav Kysela wrote:
> > > >
> > > ...
> > > > > Audio + MIDI patchbay:
> > > > >   As well as being able to route sources to destinations, the ability to
> > > > > register new audio and MIDI ports e.g. a software synth could register a
> > > > > MIDI destination and audio source and appear the same as a hardware
> > > > > device. This could provide the basis for a plug-in architecture.
> > > >
> > > > This is already done for sequencer clients (thus all MIDI and synth
> > > > devices). I'm not sure if we need digital audio (PCM) user space
> > > > drivers.
> > >
> > > I'm thinking more of a common interface for plug-ins than device
> > > drivers.
> > 
> > Can you more explain your idea? Current ALSA sequencer client in user
> > space can receive or send events and control one or more queue.
> > You can do in user space many things like:
> > 
> > 1) device drivers
> > 2) sequencer
> > 3) timer controller
> > 4) recorder
> > 5) client watcher
> > 
> >                                                         Jaroslav
> > 
> > -----
> > Jaroslav Kysela <perex@jcu.cz>
> > Academic Computer Centre, University of South Bohemia
> > Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic
> 
> What I have in mind is plug-ins a la Cubase VST etc. Here's an example:
> 
> 2 plugins: software synth (synth), software reverb (reverb); and the
> sound card (card)
> 
> card:
>   register_midi_source(midi_in)
>   register_audio_destination(audio_out)
> 
> synth:
>   register_midi_destination(syn_midi_in)
>   register_audio_source(syn_audio_out)
> 
> reverb:
>   register_audio_destination(rev_audio_in)
>   register_audio_source(rev_audio_out)
> 
> route card.midi_in to synth.syn_midi_in
> route synth.syn_audio_out to reverb.rev_audio_in
> route reverb.rev_audio_out to card.audio_out
> 
> So MIDI messages come in from the card's external input and go to the
> synth. The synth generates sound which is routed to the reverb and then
> to the card's audio output.
> 
> There could be more effects between the synth and output, or the output
> could go to a hard disk recorder. Come to that the synth could be made
> up of multiple plugins. All this is, of course is going to take a lot of
> processing power. I wonder if it might be possible to base plug-ins on
> something like csound and move some of the load to DSP chips.
> 
> 
> The way I envisioned ALSA was that the drivers would take care of the
> card specific details and the libs would provide an abstraction where
> everything was a MIDI/Audio source/destination. A MIDI destination could
> be an external port, an internal synth or a software synth but the
> application wouldn't have to know which, it would just be something you
> could send MIDI data to.

I'm not sure if routing PCM stream over kernel is good idea. What about
this scheme which is already prepared (using your example):

[MIDI generator] -> [MIDI plugin interface] -> [kernel sequencer] ->
[MIDI plugin interface] -> [software midi synth in user space] -> [PCM
plugin effect interface] -> [PCM device in kernel]

Note that ALSA driver is used here only for routing between two
applications in user space.

This means that software midi synth takes care how will be PCM output from
this device processed. We can design some plug-in interface in alsa-lib
for both PCM and MIDI devices which should parse some configuration and
use external code in dynamic libraries.

							Jaroslav

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




