From alsa-devel-owner@alsa.jcu.cz  Tue Jan 12 18:48:14 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA07745
	for <alsa-devel@alsa.jcu.cz>; Tue, 12 Jan 1999 18:46:34 +0100
Received: from someip.ppp.op.net (d-bm2-17.ppp.op.net [209.152.194.55]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA07596 for <alsa-devel@alsa.jcu.cz>; Tue, 12 Jan 1999 11:30:43 -0500 (EST)
Message-Id: <199901121630.LAA07596@renoir.op.net>
To: alsa-devel@alsa.jcu.cz
Subject: Re: Linux scheduler issues. 
In-reply-to: Your message of "Tue, 12 Jan 1999 16:43:40 +0200."
             <19990112144344Z2989-2279+2024@nic.funet.fi> 
Date: Tue, 12 Jan 1999 11:31:21 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Juhana writes:

>there is no way to do a realtime processing. Would the situation be
>different if the read()/write() buffers would be much shorter? Would the
>process switch after each read()/write()? Then it could be possible to do a
>realtime processing but, for example, direct recording to disk would fail at
>least in my system.

you can call sched_yield() after each read/write yourself, and that
will cause a context switch if there is another task ready to
run. this will give you what you want, albeit with the added cost of 2
extra kernel/user boundary crossings. However, these are very fast,
and can be mostly discounted.

--p

