From alsa-devel-owner@alsa.jcu.cz  Thu Aug 20 11:52:31 1998
Received: from heaton.cl.cam.ac.uk (exim@heaton.cl.cam.ac.uk [128.232.32.11])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id LAA14804
	for <alsa-devel@jcu.cz>; Thu, 20 Aug 1998 11:52:17 +0200
Received: from ouse.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.33.87] (dr10009)
	by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1)
	id 0z9RO9-0007BG-00; Thu, 20 Aug 1998 10:52:13 +0100
To: "Richard W.E. Furse" <richard@muse.demon.co.uk>
cc: "'alsa-devel@jcu.cz'" <alsa-devel@jcu.cz>
Subject: Re: hello, Re: Requirements? 
In-reply-to: Your message of "Wed, 19 Aug 1998 23:46:39 BST."
             <01BDCBD0.2B9BAA60@MUSE > 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Aug 1998 10:52:12 +0100
From: Dickon Reed <Dickon.Reed@cl.cam.ac.uk>
Message-Id: <E0z9RO9-0007BG-00@heaton.cl.cam.ac.uk>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


Richard raises some interesting points. 

Firstly, you are correct; for multiple applications to do mixing, scaled adds 
are necessary, but are a performance penalty. I believe it could be useful to 
switch my driver to a mode where one application has exclusive access, and so 
need only memcpy rather than mix the data in. This also means the driver need 
not clear the buffer. If the driver doesn't clear the buffer, and the 
application stops playing audio without putting silence in to the buffer 
first, then you'll get a repeating fragment of audio being played. But then 
for serious applications that want the single-source access mode, they ought 
to get it right. I intend, actually, to benchmark what difference this makes 
on the range of machines we have here. The scaled adds, I suspect, are not 
massively time consuming on any modern processor. Some applications, such as 
games and soft synthesisers, perform the scaled adds then copy data over 
themselves; this could be eliminated by usually only a rewrite of the audio 
handling code in the game.

As far as driver support goes; all I really need to do to an existing driver 
is:

- expose interrupt time stamps, preferably to processor cycle accuracy
- add code to clear the buffer slightly after playback, if mixing is to be 
performed.
- allow the buffer to be mapped into a number of applications

Then the library code needs to be rewritten for Linux, and a way needs to be 
found to get Linux to schedule processes often enough to make this useful. At 
least every 300ms, but the more regularly processes can get to run, the better.

I already have (Nemesis ports of) a few Linux applictions- dumb, timidity and 
amp, which I use for demonstrating my work.

> (Hmm George Robertson, a friend of mine, did a 
>research paper on similar issues for audio over ATM. I'll see if I can dig 
>it out--it may even be on the web somewhere.)

We first discovered it due to experience with ATM audio, as well, 
incidentally. If you find the reference, I'd be interested in reading it. Is 
http://www.research.microsoft.com/research/ui/ggr/ggr.htm the homepage of the 
same George Robertson to whom you refer.

>I usually work with 20ms as the point at which events start to sound 
>disconnected. Would it be possible to drop the fragment size say to 1024 or 
>even 512 bytes? I suspect this might present difficulties for Linux's 
>multitasking strategy.

If you mean my stuff; there isn't really any fixed fragment size; I have 
traces where some applications are writing only a dozen or so sample pairs in 
one each schedule; in such cases, the machine is being scheduled really rather 
quickly. I think you're probably about right about the 20ms figure. As I said 
in the paper, 1ms is conceivably perceivable.

Dickon



