From alsa-devel-owner@alsa.jcu.cz  Tue Apr 14 13:08:24 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id NAA04575;
	Tue, 14 Apr 1998 13:01:11 +0200
Date: Tue, 14 Apr 1998 13:01:11 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: ALSA stuff
In-Reply-To: <m0yP1jG-000aNiC@the-village.bc.nu>
Message-ID: <Pine.LNX.3.96.980414115500.1355A-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 Tue, 14 Apr 1998, Alan Cox wrote:

> One thing you want to do in your design btw is to make it possible
> for drivers to go around the ALSA code. Ie its not
> 
> 
> [syscall]---[alsa]---[driver]
> 
> but
> 
> [syscall]--[tiny demultiplexor]---[driver]---[alsa kernel library]
> 
> Thats the way most of the kernel is done so that one weird driver doesnt
> require supporting all through the core libraries but can handle the weird
> stuff itself.

This design (a little more universal) is in current driver - I had discussion
about this with Thomas Sailer.

Current design:

[syscall]--[demultiplexor]--[middle level code]--[driver]
 OR
[syscall]--[demultiplexor]--[driver]--[library]
 OR (more complicated)
[syscall]--[demultiplexor]--[middle level code]--[driver]
  [middle level code]--[library]
  [driver]--[library]
  etc...

This means - driver can register directly device in demultiplexor and
bypass all middle level code or use already written middle level code
(if hardware is compatible with used middle level scheme).

This allows (for example):

1) create more middle levels
2) handle all specific things for soundcard/chipset

I'm thinking that this solution is best. 90% of all soundcards have nearly
same hardware capabilities and for other 10% should programmers write new
code.

> Other item. For 2.2.x Im trying to finish fixing the sound module to become
> two pieces sound and oss_sound. Sound contains the alloc functions for
> getting a midi device number, synth etc and passes everything else on 
> according to the owner. So the API is basically
> 
> 	int unit=register_sounddevice(&file_ops, int type)
> 
> 	unregister_sounddevice(unit)
> 
> Will that once implemented be enough that you guys can drop your stuff on
> top of it for devel releases over 2.2, and share with OSS stuff ?

This isn't enough for alsa driver. Alsa driver creates other devices than
OSS/Lite which aren't compatible (plus OSS/Lite compatible devices, too).
Alsa driver uses different device mapping, too. Primary object is soundcard
which can have more mixer and digital audio devices. In OSS/Lite is primary
object device. In OSS/Lite is device addressed with one number, but in
ALSA driver (for some devices) with two numbers (soundcard # and device
#). Scheme for minors usage is thus different.

I recommend register to minor number (which ALSA driver does in it's
demultiplexer). ALSA driver uses minors 128-255 for native devices while
OSS/Lite uses minors from 0-127 (ALSA driver uses minors 0-127 for
compatible devices, of course). I'm thinking that this is more universal,
too..

   int error = register_sounddevice(&file_ops, int minor)

   unregister_sounddevice(int minor)

Comments?

> Alan

					Jaroslav

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



