From alsa-devel-owner@alsa.jcu.cz  Wed Apr 22 13:22:33 1998
Received: from pat.bath.ac.uk (qmailr@pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id NAA17890
	for <alsa-devel@jcu.cz>; Wed, 22 Apr 1998 13:22:14 +0200
Received: (qmail 29476 invoked from network); 22 Apr 1998 11:22:09 -0000
Received: from solomon.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.1)
  by pat.bath.ac.uk with SMTP; 22 Apr 1998 11:22:09 -0000
Received: from tobi.bath.ac.uk by solomon.bath.ac.uk id aa13314;
          22 Apr 98 12:22 BST
Message-ID: <353DD2B2.4487@bath.ac.uk>
Date: Wed, 22 Apr 1998 12:21:22 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: alsa questions + ideas [long ...]
References: <Pine.LNX.3.96.980422100042.6809A-100000@entry.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hello,

[snip]

> > In my last letter I talked about a DirectSound-like API. I think it
> > would be fine, if there would be some wavetable-related /dev/ entries
> > which hide the differencee between various wavetable cards. So it would
> > be a virtual wavetable card which would be the SAME from the view point
> > of an alsa application.
> 
> Yep.. I agree..

 You need to make sure that the interface is flexible enough to allow
you
to inquire about the wavetable card features and give you access to
these
features. Once you have implemented the standard midi stuff you also
need
need a list of special effects. I do this in my software as a layer
ontop
of the /dev/sequencer driver. It is probably best to implement each
sound card
driver in the most effiecent manner and provide an wrapper based on an
absract
interface for each device.


> > How can I learn more about the alsa concept ? It's very good that alsa
> > is a multi module layered architecture so a module is for the sound
> > driver in gerneral, a module for the chipset etc. I hope that the "interface"
> > of these modules will be standard. I think idea of free softwares, the
> > FSF, GPL feeling are great, but ... the computer market unfortunetly aren't
> > based on the freedom. So it would be nice to create a STANDARD allowing
> > hardware developers to create binary drivers for their product under Linux
> > too. What do you think about it ? (and it's not only for alsa ...
> > it would be nice EVERYWHERE ... Linux is great (I'm using only Linux)
> > but non-programmers can't (and don't want to) compile kernels, drivers,
> > etc ...)
> 
> I'm saying NO... This is currently impossible do cross-kernel version
> binary kernel modules... If some company want make driver without sources,
> it can use staying interface (header files for user space) and make all
> code in own way... If we make some proposal of internal interface then we
> can't make some changes in this interface in future... This cause stop of
> evolution of driver and gives down power of Linux. If you look to 2.0
> kernel and 2.1 kernel there are in internal interfaces are very big
> changes (for example select isn't present in 2.1, new is poll).
> 
> To binary distributions: It depends on distribution creators which kernel
> modules add to your distribution.

 I would not like to leave the interface software to my AWE32 in the
hands of
creative labs. The linux stuff written by Takashi (spelling) is far more
flexible
than the creative labs AWE32 API.

> > Is it planned to support SB awe cards too ?
> 
> SB AWE cards are supported in ALSA, but I should say that I probably
> willn't work on WaveTable code for EMU-8000 chips...

 I think the awe32 code that Takashi wrote to plug into the oss stuff
would make it a very easy job for anyone that knew what they were doing.
If  my  guess work is correct then the interface between OSS and the awe
code is done via this function table.

/*----------------------------------------------------------------
 * synth operation table
 *----------------------------------------------------------------*/

static struct synth_operations awe_operations =
{
#ifdef AWE_OSS38
        "Emu8000",
#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
};



 Cheers Paul.                                        
               __         __                  
              (  ) _ - _ (  )                 
               ~~         ~~                  
                (  0   0  )                   
----------ooO----(       )----Ooo------------ 
          '''     (     )     '''             
                   (   )                      
                    \ /                       
                   ~~O~~                      

  Tel: +44 1225 826108
  Fax: +44 1225 826305
snail: P.J.Leonard
       Applied Electromagnetic Research Centre
       Bath University,
       BATH, UK   BA2 7AY

