From alsa-user-owner@alsa.jcu.cz  Fri Apr 24 00:52:19 1998
Received: from casema.net (smoke@3dyn34.delft.casema.net [195.96.104.34])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id AAA14502
	for <alsa-user@jcu.cz>; Fri, 24 Apr 1998 00:51:55 +0200
Received: (from smoke@localhost) by casema.net (8.6.12/8.6.9) id AAA22994; Fri, 24 Apr 1998 00:50:06 GMT
Date: Fri, 24 Apr 1998 00:50:06 +0000 (GMT)
From: Smoke of Crap <smoke@casema.net>
To: alsa-user@jcu.cz
cc: 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.91.980424004644.22968A-100000@smoke>
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



okay :)

perhaps you didn't really understand me.. I have been writing DOS demos 
for quite some time and got used to coding 70fps effects.. Now in a 
multitasking environment like linux everyone thinks 30 fps is great; but 
I really want to get the most out of my hardware..

If I have to skip 2 frames, things won't be that nice.. And I wonder 
whether a buffer that starts after 0.25 seconds is usable.. For a tracker 
for example one wants to play music on the keyboard.. Well it might be 
just fast enough.. But experimenting with Linux showed me that the 
#define HZ 100 is defined too low, in order to sync with the vertical 
retrace for example. I'm quite sure I have to use rtLinux..

Perhaps I'm still mistaken, and _please_ try to convince me I'm wrong, 
for I think it'll take a lot of time to figure everything and then come 
up with something completely useless ;)

Thanks!



On Thu, 23 Apr 1998, Jaroslav Kysela wrote:

> On Thu, 23 Apr 1998, Smoke of Crap wrote:
> 
> > 
> > 
> > Hi,
> > 
> > i'm interested in this driver mainly because i'm working on a tracker as 
> > a part of a nice demo-oriented project. I'm using a GUS classic and i 
> > can't seem to figure how to do a real good modplayer with good timing. 
> > After fiddling with RtLinux a bit, i figured it'd be nice to have a hard 
> > real time task that runs a modplayer.
> > 
> > Now my question:
> > 
> > does any of you know how to do the innerloop of the player in a 
> > kernel-module (kernelspace) without having to rewrite my own gus drivers 
>   ^^^^^^^^^^^^^
> Is this really needed? Modplayer is job for application, not for kernel..
> 
> > ? (as i already did) Can i keep using /dev/dsp ? Has any of you ever 
> > tried something alike?
> > 
> > My problems were : 
> > 
> > - gmod buffers and can't be used to synchronize with video-effects
> > - mikmod uses /dev/dsp only and gives terrible results on a GUS Classic, 
> > which prefers hardware-mixing
> > - i found it hard to create a rtLinux module that does the timing needed 
> > for the player.. could i do this in another way that still allows me to 
> > have a good update of graphics ? (70 frames per second)
> 
> I think that best solution for you will be two processes - one for
> graphics and second for sound which should communicate over IPC (threads
> shouldn't be necesarry - fork is ok). Both processes should be
> synchronized with system time (look to function gettimeofday).
> 
> Graphics process loop:
> 
> 	diff_time = gettimeofday() - previous_time;
> 	if (diff_time >= time_for_frame) show_frame;
> 	diff_time -= time_for_frame;
> 	usleep( time_for_frame - diff_time );
> 
>   Note: diff_time should be (if system is slow or if some other
>         process eat much CPU time) bigger or equal than 2*time_for_frame,
>  	thus graphics process _MUST_ skip frames...
>   Note: start time should be synchronized with sound process
> 
> 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...
> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@jcu.cz>
> Academic Computer Centre, University of South Bohemia
> Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic
> 
> ------
> To unsubscribe from <alsa-user@alsa.jcu.cz> mailing list send message
> 'unsubscribe' in the body of message to <alsa-user-request@alsa.jcu.cz>.
> 

