From alsa-user-owner@alsa.jcu.cz  Thu Apr 23 23:12:57 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id XAA08712;
	Thu, 23 Apr 1998 23:12:49 +0200
Date: Thu, 23 Apr 1998 23:12:48 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Smoke of Crap <smoke@casema.net>
cc: alsa <alsa-user@alsa.jcu.cz>
Subject: Re: gus modplayer (take #2)
In-Reply-To: <Pine.LNX.3.91.980423220638.173C-100000@smoke>
Message-ID: <Pine.LNX.3.96.980423224436.2322B-100000@entry.jcu.cz>
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, 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


