From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Locked Streams in Allegro Date: Tue, 3 Mar 1998 23:31:10 +0000 Organization: None Message-ID: 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 Precedence: bulk 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