From ultra-devel-owner@ultra.jcu.cz  Mon Feb 23 22:00:30 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 WAA12574;
	Mon, 23 Feb 1998 22:00:25 +0100
Date: Mon, 23 Feb 1998 22:00:25 +0100 (MET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
cc: Daniel Bergstrom <daniel@futurniture.se>, ultra-devel@ultra.jcu.cz
Subject: Re: [sailer@ife.ee.ethz.ch: Sound...]
In-Reply-To: <34F1A7AB.4893@ife.ee.ethz.ch>
Message-ID: <Pine.LNX.3.96.980223210628.2263F-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 Mon, 23 Feb 1998, Thomas Sailer wrote:

> Very good... as MIDI is not what interests me :-)
> 
> What I would like to prevent is these things (i.e.
> MIDI, mixer, Synth and PCM) becoming too interleaved,
> like in Hannu's code, I'd like to keep em as separate
> as possible...

I agree... Can you look (if you have a few minutes free) to my code and
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
quake is doing realtime mixing of sound effect - this feature needs
minimize time to output mixed effect to output. If application setup small
fragments -> application can in most cases cause underrun. If buffers 
will be bigger -> there will be delay in output. Linux isn't realtime very
much, but in right mmaped access (don't think that OSS have right mmaped
access) - application can with very good precision compute current
position in PCM stream and place new effect to right place. What about
timestamp in which was processed last fragment / begin new fragment in
mmaped DMA buffer?

OK. Next note: Is your code realy fullduplex? I see your code and in wss
driver you setup always only record or only playback bit in
indirect register 9. Supports your code two open calls (first with
O_RDONLY and second with O_WRONLY) by two different processes?

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?

> 
> Tom
> 

					Jaroslav

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


