From alsa-devel-owner@alsa.jcu.cz  Wed Aug 19 12:14:22 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 MAA21775
	for <alsa-devel@jcu.cz>; Wed, 19 Aug 1998 12:13:46 +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 0z95FR-0006hd-00; Wed, 19 Aug 1998 11:13:45 +0100
To: alsa-devel@jcu.cz
Subject: hello,  Re: Requirements?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 19 Aug 1998 11:13:42 +0100
From: Dickon Reed <Dickon.Reed@cl.cam.ac.uk>
Message-Id: <E0z95FR-0006hd-00@heaton.cl.cam.ac.uk>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


(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 
Europe. I've made some progress on the Nemesis version of my audio 
architecture, but I'm interested in seeing whether the ideas are applicable on 
other operating systems.

In essence, the way my experimental device driver works is to provide all 
applications with direct access to the DMA buffer of the sound card. The 
device driver mediates access to the buffer, records the time of each 
interrupt and from that calculates the exact playout rate of the sound card, 
and clears the DMA buffer out periodically, clearing the part of the buffer 
that the sound card has just played. Applications use a library to place a 
number of samples in to the buffer, and thus get to choose their play out 
latency. I've measured latencies as low as 500us, where most of that remaining 
time is the time taken to by the sound card to play the data after DMAing it 
across the ISA bus. If anyone wants to see the numbers and comparisions with 
other operating systems, or the background, they may like to read:

http://www.cl.cam.ac.uk/~dr10009/audio/audio.html

The main advantage of this scheme is that clients may choose how much data to 
write at once, and exactly what latency it should have (but the lower latency 
they choose, the more often they have to deliver data to the sound card, which 
may be a problem on most operating systems). You also get mixing of different 
audio streams for free.

I'm thinking about recording now; I believe the same idea can be used to do 
(for instance) very low latency signal processing. Incidentally, can anyone 
recommend particular commodity sound cards that have full tech specs 
available, manage full-duplex audio at CD quality both ways, preferably PCI, 
and are available in the UK? I'm having trouble finding suppliers for anything 
apart from sound blaster clones, and full duplex on SB clones seems to be 
mostly limited to 8 bits on way, 16 the other, which is a bit naff really.

At the conference where the paper I gave a reference to above was published, a 
lot of people wanted to see better audio drivers for Linux. ALSA seems to be 
moving in the right direction. As far as I can see, the main problem with 
doing what I'm trying to do on Linux is likely to be getting applications to 
run frequently and reliably enough to play audio in to the buffer.

On to Richard's points, which incidentally I found very interesting:

>1. Synchronising audio outs. If I wanted to output simultaneously from my 
>AWE32 and FIJI then how would I find out at runtime enough information to 
>calculate when to pass packets of audio, start timers or whatever to sync 
>the devices as well as possibl

This is esay under my scheme; the application would choose to play both the 
streams with the same latency, by calculating using each device driver's 
statistics where in each buffer each sound card was currently playing, and 
writing the same number of samples ahead.

>2. How to sync MIDI & audio in a hardware independent way?

I' don't know much about MIDI on PCs, I'm afraid. But at least the application 
is aware of exactly when the audio will play out (assuming the device drivers 
know how long the playout FIFOs on the sound cards are).

>3. How to sync playback and record (so that afterwards it is clear when 
>recorded sound/events happened relative to sounds and events played?

I hope that when I've got recording working I'll be able to investigate this 
issue. Essentially, I'd want the application and device drivers to all be 
working in real time, so synchronisation to be as accurate as the device 
drivers permit.

>4. How to sync playback to screen updates?

This may be tricky if you're using a large, monolithic display service like X, 
because it's very hard to predict how long updates will take after the 
application sends the data. However, if you can get direct unprotected access 
to the frame buffer (ie DirectX, DGA, SVGALIB, etc), then you can tell how 
long the updates take). (In fact, on Nemesis, you get direct protected access, 
but that's another story).

>4b. How can the program find out what buffering if in use? Differing packet 
>sizes and queue lengths for devices cause synchronisation issues and 
>potential blocking issues for developers. Do all sound cards support one 
>buffer size? How much audio is required before playback or recording 
>actually begins etc etc. Can this be found through the API?

A good question. In my scheme, most of this is up to the application anyway. 
The unknown parameter might be the play out buffer of the sound cards 
themselves; at least the SB clones I've worked with have FIFOs of typically 
around 440us. This is small compared to what most device drivers on most OSes 
manage, however. (I actually mesaured 200ms on NT with DirectSound!)

>5. And an extreme case which brings these problems into real focus: if I 
>wanted to use my PC as a guitar effects processor, how would I set up the 
>buffers etc for this to minimise delay? With in & out on different sound 
>cards?. How would the program find the information to work out if this is 
>possible at all?

Funny you should mention this, but one of my undergraduates wrote just such a 
project last year, on Nemesis using my device driver for playback. For that 
project, we recorded audio on an "ATM camera", sent the stream across an ATM 
network, through two switches, and played the data out. The effects processing 
algorithms contributed about 5ms of end-to-end delay, and the network another 
4ms, and we had the application introduce a latency of 1ms so we only had to 
schedule it every 1ms. Worked great, apart from play rate mismatching.

(Play rate mismatching is an effect caused by no two sound devices having 
identical clocks. Typically they'll be off by a few parts per million, so, for 
instance, you may record at 44.1001 kilohertz, and playback at 44.0999 
kilohertz. The result is that samples pile up in whatever buffering you have 
between recording and playback, and you have to do sample rate 
microadjustments.)

I hope this is interesting to people, and would be very interested in any 
feedback. I'm reading, as time permits, the ALSA source and docs.

Dickon Reed
Cambridge University Computer Laboratory
UK





