From alsa-devel-owner@alsa.jcu.cz  Thu Aug 20 01:24:03 1998
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id BAA07467
	for <alsa-devel@jcu.cz>; Thu, 20 Aug 1998 01:22:20 +0200
Received: from (MUSE) [158.152.21.220] 
	by post.mail.demon.net with smtp (Exim 1.82 #2)
	id 0z9HYS-0006QV-00; Wed, 19 Aug 1998 23:22:12 +0000
Received: by MUSE            with Microsoft Mail
	id <01BDCBD0.2D487000@MUSE           >; Thu, 20 Aug 1998 00:19:20 +0100
Message-ID: <01BDCBD0.2D487000@MUSE           >
From: "Richard W.E. Furse" <richard@muse.demon.co.uk>
To: "'alsa-devel@jcu.cz'" <alsa-devel@jcu.cz>,
        "'Dickon.Reed@cl.cam.ac.uk'" <Dickon.Reed@cl.cam.ac.uk>
Subject: RE: hello,  Re: Requirements?
Date: Wed, 19 Aug 1998 23:46:39 +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hmm. Interesting stuff and the web page is well worth a visit.

I must admit as a serious audio application developer I rather like the 
idea of having audio ports to myself. Not good to have a keyboard bing pop 
out of your amplifiers in the middle of a concert... But then this is a 
rather specialist field--audio has so many other uses: music playback, 
internet phones, sound effects for games, user interface prompts etc etc. 
In this context single-process access to soundcards is rather unhelpful. 
I'm pretty sure there used to be some kind of sound-effect server available 
for Linux. Is this still around? If so, if anyone is actually using it then 
perhaps it should be in the kernel?

Perhaps it would be possible to separate Dickon's abstraction into two 
separate layers and allow the upper 'mixer' layer to be switched on and off 
for each soundcard in the machine, although depending on the implementation 
of the lower 'raw' drivers this might lose the performance advantage or 
being able to write direct to DMA buffers. The raw driver layer would 
provide information about latency, packet size, buffer length 
etc--information that existing drivers will hopefully be able to provide. 
My gut suggests that the mixer layer would be quite costly on pre-MMX 
machines as they would use scaled adds rather than simple memory copies 
when playing Doom, which already will have mixed the sounds once...

Incidentally, the 'mixer' layer is not unlike a system I've been using for 
interactive pieces on Windows (old style, not DirectSound) and Linux 
although the many client ('slave') threads/processes insert sounds (stored 
in a file system in memory/shared memory) into a virtual multitrack 
maintained and scrolled by the server ('master') thread/process. This is 
very limited but gets around most latency problems. Dickon's abstraction is 
much nicer but relies on guarantees of time for slaves to complete 
processing ahead of playback. I like the latter idea--very much in the 
spirit of ATM and would solve a lot of my problems. I don't suppose if 
anyone knows if Linux or Windows are likely to support this anytime soon? 
I'll look at Nemesis when I have time.

In summary, I think this architecture is very useful. Firstly for direct 
application 'multimedia' operating systems--it would be nice to have on 
Linux as an additional layer on top of the core sound drivers or as an 
alternative driver (at the soundcard level). Secondly as food for thought.

-- Richard

-----Original Message-----
From:	Dickon Reed [SMTP:Dickon.Reed@cl.cam.ac.uk]
Sent:	Wednesday, August 19, 1998 11:14 AM
To:	alsa-devel@jcu.cz
Subject:	hello,  Re: Requirements?

(perhaps I should introduce myself before following up to Richard's 
article).

Hello. I'm a research student working on, among other things, audio device
drivers. Most of my work has been on a research operating system called
Nemesis, which we are working on here along with several other sites around
[...]
