From alsa-user-owner@alsa.jcu.cz  Fri Apr 24 10:14:41 1998
Received: from hermes.rus.uni-stuttgart.de (hermes.rus.uni-stuttgart.de [129.69.1.70])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id KAA14549
	for <alsa-user@alsa.jcu.cz>; Fri, 24 Apr 1998 10:14:39 +0200
From: erikyyy@studbox.uni-stuttgart.de
Received: from vulcain.yyydom (erik@rusxppp144.rus.uni-stuttgart.de [129.69.31.144])
	by hermes.rus.uni-stuttgart.de (8.8.8/8.8.8) with SMTP id KAA15828
	for <alsa-user@alsa.jcu.cz>; Fri, 24 Apr 1998 10:14:37 +0200 (MET DST)
	env-from (erikyyy@studbox.uni-stuttgart.de)
Date: Fri, 24 Apr 1998 10:14:27 +0200 (CEST)
To: alsa <alsa-user@alsa.jcu.cz>
Subject: Re: gus modplayer (take #2)
In-Reply-To: <Pine.LNX.3.96.980423224436.2322B-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.3.96.980424100745.472A-100000@vulcain.yyydom>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-user@alsa.jcu.cz
Sender: alsa-user-owner@alsa.jcu.cz
Precedence: list

On Thu, 23 Apr 1998, Jaroslav Kysela wrote:

> Sound process loop:
> 
> 	This loop should be standard using write and select functions.
> Fragment size for audio buffer should be set to some reasonable time
> (0.25sec?). Sound process should pass to graphics process time when
> was playback started (and current playback time?) for better time
> synchronization of sound and graphics.
> 
> Above are only basic ideas how can be good demo/game programmed...

you can use sched_setscheduler() and mlockall() to make the sound process
a realtime process. mlockall() prevents it from being swapped out to disk,
sched_setscheduler() can be used to give it maximum system priority.
BEWARE! if your sound server has an endless loop, you have to press RESET,
unless you have a bash running at higher realtime priority.
BEWARE2! both commands only work if you are root. this is why x11amp needs
to run as root.
you should make it possible to run your program as normal user, too.
therefore, avoid calls to malloc() while mixing, and use reasonable buffer
size. (you should use MANY SMALL fragments, not TWO BIG fragments)

there will be another bad effect to fight against, if your sound process
is not running at higher priority than your graphics process:

if the graphic process uses 100% (it usually does so) CPU time, your sound
process may click sometimes :) so you should let your soundprocess tell
the graphics process, when to display the next frame. this way, the
graphics process will only use 100% for a single frame. then it waits for
the sound process again.
as this is not really good, you could also let the sound process send the
graphics process a SIGSTOP in case of an emergency. (100 buffers are
empty, and only 5 left) afterwards you can send a SIGCONT.


do what you like :-)

byebye
erik


--
EMAIL: erikyyy@studbox.uni-stuttgart.de                  \\\\
       thieleek@tick.informatik.uni-stuttgart.de         o `QQ'_
IRC:   erikyyy                                            /   __8
WWW:   http://wwwcip.rus.uni-stuttgart.de/~inf24628/      '  `
       http://tick.informatik.uni-stuttgart.de/~thieleek/


