From alsa-devel-owner@alsa.jcu.cz  Mon Jan 11 11:45:22 1999
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id LAA07126
	for <alsa-devel@alsa.jcu.cz>; Mon, 11 Jan 1999 11:41:44 +0100
Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <2631-2281>; Mon, 11 Jan 1999 12:11:22 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: alsa-devel@alsa.jcu.cz
Cc: Benjamin GOLINVAUX <golinvaux@benjamin.net>
In-reply-to: <199901092046.PAA25489@renoir.op.net> (message from Paul
	Barton-Davis on Sat, 09 Jan 1999 15:46:39 -0500)
Subject: Re: Hi - need some help?
Message-Id: <19990111101124Z2631-2281+1905@nic.funet.fi>
Date: 	Mon, 11 Jan 1999 12:11:22 +0200
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

>Its not latency that is the heart of the problem. The difficulty is
>whether the scheduler gets in the way at a critical moment.

The Linux's process scheduler? Not the scheduler of an audio software?
Would somebody tell me what exactly happens inside the Linux when
one (or two) processes of an audio software runs? What happens when
read() or write() is used? What practically is a non-blocking mode?
I'm aware of the non-blocking mode and know the call returns immediately
but what happens there? If there is no time spend in reading, then where
the data come from? Or is the data buffered for the next read() call?

I have heard a process is changed perhaps 20 times per second, that is
50 ms latency. What happens when nice is changed toward + or - direction?
If latency decreases, then we only need to test if a particular computer
and nice value makes the system fast enough for audio work. Just like
I planned to test the recording possibilities for my shmrec.

Yours,

Juhana

