From alsa-devel-owner@alsa.jcu.cz  Fri Apr 24 10:11:50 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 KAA14307;
	Fri, 24 Apr 1998 10:10:46 +0200
Date: Fri, 24 Apr 1998 10:10:46 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Smoke of Crap <smoke@casema.net>
cc: alsa <alsa-user@alsa.jcu.cz>, alsa-devel@alsa.jcu.cz
Subject: Re: gus modplayer (take #2)
In-Reply-To: <Pine.LNX.3.91.980424004644.22968A-100000@smoke>
Message-ID: <Pine.LNX.3.96.980424092107.6191B-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Fri, 24 Apr 1998, Smoke of Crap wrote:

> 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 

Yes, but system is up and all services should be running... Assume that
some system administrator runs your demo on server with good hardware
which runs some services that aren't time consuming at moment. In some
time when demo is running some service eat CPU time and you should
synchronize graphics and maybe sound for new timing...

> 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 

This is problem... There is some delay for system delivers MIDI data to
application and next delay can be caused by application which should 
compute and write new data for digital audio stream...

I'm planning emulate MIDI THRU in driver which passes MIDI data from some
input interface (for example) to internal syntesizer in interrupt routine.
Delay should be minimal in this case. Maybe something should be done for
programmed syntesizer interface (for modplayers/trackers) and tracker
should only record (with some buffering) input events. This can't be done
for digital audio stream (PCM) of course (even driver should support
software mixing, but there will be delay in all cases)..

> 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..

You can use rtLinux or some other non-standard patches, but don't assume
that most of people will execute your program... Most of people doesn't
know about compilation of Linux kernel or other system deep things
anything...

To vertical sync - it's a little bit unpossible use some polling mode for
vertical sync without write special VGA driver... In other cases will be
detection of vertical sync very time consuming and you lost most of power
of CPU for this. In multitasking enviroment good program _MUST_ wait for
events and not use polling mode (loop which tests some condition from
hardware). I'm thinking that GGI project does some framebuffering. Look
for it.

> 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 ;)

Please, we are now a little bit of theme (realtime graphics isn't goal
of this project) and alsa-user mailing list is for users (installation
problems, application problems etc...). Maybe we can switch this
discussion to alsa-devel mailing list without notes about graphics
(or with minimal notes about graphics and sound synchronization)..

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic



