From ultra-devel-owner@ultra.jcu.cz  Tue Feb 24 21:25:11 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 VAA20942;
	Tue, 24 Feb 1998 21:25:08 +0100
Date: Tue, 24 Feb 1998 21:25:07 +0100 (MET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
cc: ultra-devel@ultra.jcu.cz
Subject: Re: [sailer@ife.ee.ethz.ch: Sound...]
In-Reply-To: <34F2F2A6.643C@ife.ee.ethz.ch>
Message-ID: <Pine.LNX.3.96.980224185438.8668D-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: ultra-devel@ultra.jcu.cz
Sender: ultra-devel-owner@ultra.jcu.cz
Precedence: list

On Tue, 24 Feb 1998, Thomas Sailer wrote:

> > I agree... Can you look (if you have a few minutes free) to my code and
> 
> Your code? Is this the Gravis Ultra Sound project?
> (Sorry to ask such a stupid question...)

Nope, it's mostly new code, but some stuff are copied from The Linux Ultra
Sound Project, but totaly rewritten to make stuff modularized and allow
support any soundcard. This is what I'm doing about last three or four
weeks...

> > send me what you think about it? I looked to your PCM interface (API) -
> > very good for buffering (simple and covers all new OSS features),
> > but any form of buffering can delay output (mmaping doesn't). For example
> 
> Yes mmap does too unless you risk dropping samples...
> write doesn't necessarily do more buffering, you need not fill
> the whole buffer all the time :-)  But the driver needs to tell
> the max. wakeup latency to be expected.

I see that your method can be more useable for Unix. I can do some
work on OSS PCM API emulation (I have it nearly complete in my new
driver).

> > OK. Next note: Is your code realy fullduplex? I see your code and in wss
> 
> I start to wonder where you have seen my code. :-)
> 
> The one on my harddisk is... 

I find in one forwarded mail from Daniel Bergstrom URL (audio.diff) for
your source (maybe for 2.1.79 kernel), but it maybe probably old.

> > Last and probably most important question: Are you thinking that we can
> > merge our work together and create new, enhanced and robust sound driver
> > and API for Linux?
> 
> Why not?

Fine. Please, again, look to my sources at ftp://ultra.jcu.cz/pub/driver...
I think that my sources is better modularized...

I have setup some resources WWW, FTP and mailing lists for my new project
here at university where I'm working. Project was named at first 'The
Ultra Sound Driver', after this 'Enhanced Linux Sound Architecture' (ELSA)
and see that I must change name again to 'Linux Enhanced Sound
Architecture' (LESA) due to conflict with deutch manufacture ELSA.
For me isn't problem rename sites from ultra to lesa or something other if
you have better idea.

Next thing - I have my project more complicated. I'm thinking that some
code for sound support is need to do in user space, but it can be
shareable -> sound library. I think that library can cover Kernel Sound 
API and add more power code (for example PCM mixing, instrument loading,
synthesizer queue management etc...).

There is also need some configuration manager for sound kernel modules.
This program will cover functionality of kerneld and autodetection
features of new driver etc... This program is strongly needed for most
normal users.

All above things are mentioned on URL http://ultra.jcu.cz...

> Tom

					Jaroslav

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




