From alsa-devel-owner@alsa.jcu.cz  Sun Aug 16 11:43:18 1998
Received: from localhost (perex@localhost)
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id LAA04545;
	Sun, 16 Aug 1998 11:42:48 +0200
Date: Sun, 16 Aug 1998 11:42:48 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: "Richard W.E. Furse" <richard@muse.demon.co.uk>
cc: "'alsa-devel@alsa.jcu.cz'" <alsa-devel@alsa.jcu.cz>
Subject: Re: Requirements?
In-Reply-To: <01BDC83F.2A437240@MUSE           >
Message-ID: <Pine.LNX.3.95.980816110503.1145A-100000@marvin.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Sat, 15 Aug 1998, Richard W.E. Furse wrote:

> Introduction: I'm an electro-acoustic composer/programmer & I've been 
> working on powerful sound tools, mostly for Linux, for the past few years. 
> These tools have mostly been batch based (output heard using vplay) but I 
> did write a couple of (poor) real-time algorithmic compositions through the 
> Voxwave (sp?) interface.
> 
> I'm currently working on an ambitious project possibly for public release. 
> I've decided on Java as the main platform with RNI/JNI links to native 
> methods to provide efficient versions of numerically costly processing and 
> to access audio hardware. The vague plan at the moment if to release free & 
> first on Linux and then release commercially on Windows.
> 
> I've written a Windoze version of the audio connection objects without 
> trouble. Haven't looked at MIDI yet. I then looked into the current state 
> of the Linux sound drivers and found the OSS/"Free" mess. So now I'm here.
> 
> I like the sound of this project and can make a little time to help out if 
> I can. I'm a fast and experienced professional developer with a good 
> theoretical understanding of audio. A first project of interest to me might 
> be sound drivers for my current main audio card (a Turtle Beach Fiji).

You are welcome.

> I'm even more interested in ensuring that the API being developed at 
> present will provide adequate flexibility for myself and other potential 
> multimedia developers.

ALSA wants to be flexible as prossible. 

> The big problem area from my perspective is synchronisation. I had a quick 
> look at the existing API and didn't immediately see what I was looking 
> for--but then I didn't spend too long on it. I'm interested in how I might 
> be able to approach each of these issues--I'm sure some of the problems 
> below are insurmountable and some are already resolved--but I won't know 
> unless I ask. I hope my questions are not too stupid!

Synchronisation is big problem for us and maybe other developers (for
example realtime graphics etc.).

> Let us consider a fully featured multitrack. Such a program might attempt 
> simultaneous playback and record using a number of devices including MIDI, 
> audio and screen updates.
> 
> 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 possible?

You should know that sequencer isn't done for ALSA yet. You can look to
proposal how is sychronisation planned (link is from http://alsa.jcu.cz).

The basic thing for synchronisation is _ONE_ time source. The best source
is absolute system time in microsecond resolution. We can use in kernel
space gettimeofday(), but here trouble begins: Assume that you have usual
computer connected to InterNet and it's time is synchronized via NTP
protocol hourly. Assume that clock in your motherboard aren't very precise
- differece is about +-0.01ms per hour. Each hour system time is
incremented with this difference. This makes synchronisation very
complicated or maybe I'm wrong how adjtimex() works. The total another
thing is if user change system time. Application should be totaly
unsychronised after this.

On other side - this synchronisation source will use general world time
and you will be able synchronise applications which runs on more
computers.

Or maybe someone have another idea how can be sychronisation done?

OK. Audio should be synchronised over system time in which playback/record
starts.

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

Only rawmidi is designed yet (no sequencing is done by kernel). You should
use system time (same as for digital audio) for synchronisation.

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

Digital audio - look to 1)
MIDI - not done yet
RawMIDI - look to 2)


> 4. How to sync playback to screen updates?

If you have one sychronisation source - in our case system time you can
use it for all other things (include screen updates), too.

> 4. 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?

Yes. You can get these information over playback/record status.
Appropriate structures contains fragment sizes (piece of ring output
buffer) and number of fragments in use. You can also set low and high
watermark when application can write / read data from audio stream.

> 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?

Same answer as in 4). You can set fragment size and high watermark
(maximum number of fragments filled in ring buffer) for playback and
fragment size and low watermark (minumum fragments filled in ring buffer).

For example:

Fragment size for playback/record = 4096
Low record watermark = 1
High playback watermark = 2	(one is bad idea - underruns will be occured)

OK. Now you can use standard select() loop and read data from stream and
write (after some processing is done) to stream. Delay which will be
caused with this settings will be (assume 44100Hz rate, 16-bit, stereo):

3 * 4096 bytes = 12288 bytes per second (one record fragment +
                                         two playback fragments)
44100 * 2 * 2 = 176400 bytes per second

12288 / 176400 = 0.069659863 seconds (about 70ms) delay

This delay should be a little high (playback probably willn't start at
same time when second record fragment will be received).

						Jaroslav

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


