From alsa-devel-owner@alsa.jcu.cz  Thu Feb  4 19:46:53 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id TAA13407;
	Thu, 4 Feb 1999 19:46:37 +0100
Date: Thu, 4 Feb 1999 19:46:37 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Andy Lo A Foe <arloafoe@cs.vu.nl>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: latency..
In-Reply-To: <Pine.GSO.4.05.9902041547590.20391-100000@galjas.cs.vu.nl>
Message-ID: <Pine.LNX.3.96.990204192401.12560B-100000@entry.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 Thu, 4 Feb 1999, Andy Lo A Foe wrote:

> Hmm, it looks like the latency problems might come due to my soundcard
> being ISA based. I've got some respons back from Christopher Lansdown and
> he has much better results with his PCI based soundcard. Maybe some things
> changed for the worse regarding ISA card in the new kernels/ALSA?!

Nope. ISA cards have always latency between 3-4ms. The problem is that
"prepare" part of lowlevel driver eats in some cases some task time. This
could cause serious delay between real start of playback.

'+' means application steps and '*' means driver steps:

- read two fragments
* prepare record
* start record
- write two fragments
* prepare playback <- this operations could cause delay !!!
* start playback

As you see, the best way for loopback is:

* prepare record
* prepare playback
- read two fragments
* start record
- write two fragments
* start playback

I'm thinking about adding 'prepare' ioctls for playback and record to let
an application control this behaviour. I'm also thinking about 
synchronized playback and record, but only if the hardware allows it
(something or same thing like TRIGGER in OSS PCM API). Any comments?

							Jaroslav

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




