From:	Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Locked Streams in Allegro
Date:	Tue, 3 Mar 1998 23:31:10 +0000
Organization:	None
Message-ID:	<b8tF7EA+KJ$0EwBF@talula.demon.co.uk>
References:	<01bd3a85$0198e2a0$0201a8c0 AT technoid>
NNTP-Posting-Host:	talula.demon.co.uk
MIME-Version:	1.0
Lines:	47
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Luke Bishop writes:
>I was wondering why you couldn't fill an Allegro audio stream from a 
>timer routine? I looked through the source code and even changed it to 
>lock the functions myself. There seems to be nothing stopping it from 
>working.

This might work for some programs, but there are some subtle problems
with doing it, and various reasons why I didn't bother to support it
properly:

- Because the SB mixing code is itself running in an interrupt context,
there is a potential for dual reentrancy (your buffer refill could
interrupt the code that is reading data from the buffer, or the data
read could interrupt your refill operation). It isn't impossible to make
that work reliably, but it is a considerable pain and not something that
I want to do without a really good reason! The DIGMID driver suffered
from a similar kind of problem, and it took forever to get rid of all
the random crashes caused by interrupts going off at the wrong times.

- It is very easy to do audio streaming on the SB (which is the only
currently supported digital output device), but any future drivers for
wavetable cards like the GUS will need to do far more work in order to
send each section of the waveform across to the soundcard. In some cases
this might involve operations that don't work well inside interrupt
handlers, and it seems silly to impose restrictions on the basis of just
one driver if there is any chance that they might cause problems when
trying to support other hardware at a later date.

- Interrupt handlers are nothing like as flexible or stable as the
mainline code, and are a big nuisance because you need to lock all the
memory they use. I think it is generally good program design to do as
much work as possible in the body of your program, and only use an
interrupt handler where there is absolutely no other alternative, so it
isn't something that I am overly concerned about supporting.

- In terms of overall usefulness, what would you really be able to do
from a timer based stream update? In most cases I imagine that audio
streaming code will either be reading a waveform in from disk on the fly
(impossible from an interrupt handler), or doing some relatively
expensive calculations to generate it (not a good idea from an interrupt
handler because it can upset the timer accuracy, and will crash horribly
if your code ever starts taking longer than the timer speed).


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Pigs use it for a tambourine" - Frank Zappa

- Raw text -