From alsa-devel-owner@alsa.jcu.cz  Mon Oct  5 13:49:39 1998
Received: from ife.ee.ethz.ch (ife-delek-fast.ee.ethz.ch [129.132.2.204])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id NAA21134
	for <alsa-devel@jcu.cz>; Mon, 5 Oct 1998 13:48:44 +0200
Received: from ife.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id NAA05559
	for <alsa-devel@jcu.cz>; Mon, 5 Oct 1998 13:47:51 +0200 (MET DST)
Message-ID: <3618B20E.8AD559F5@ife.ee.ethz.ch>
Date: Mon, 05 Oct 1998 13:48:30 +0200
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
MIME-Version: 1.0
To: alsa-devel@jcu.cz
Subject: Re: PCM mixing draft v0.2
References: <Pine.LNX.3.96.981004223424.4361N-100000@entry.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:

> OK. Looks like main problem is good scheduler. I see that in both cases is
> main delay caused by task scheduler now. Current Linux scheduler is
> probably limited with system clock (100Hz on i386). This means that delay
> should be up to 20ms (or I missed something?). Other delay should be added
> by effects, filters, conversions etc, but this must be done in both cases.

I don't quite see what problems ppl have with the Linux scheduler.
The basic sched tick is indeed 100Hz on i386, but that doesn't mean
it can only reschedule at 10ms boundaries. If your driver wants it,
Linux can also reschedule at the end of a sound driver interrupt for
example (see the need_resched stuff).

Tom

