From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stas Sergeev Subject: Re: various dosemu comments and hacks (sound, delays) Date: Mon, 24 Feb 2003 20:48:27 +0300 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <3E5A5AEB.9010309@yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-msdos@vger.kernel.org Hello. Ryan Underwood wrote: > be used as a smooth speed throttle. :) If you can come up with a > better delay, be my guest. Well, I've no idea about a precision you need, but if the precision of usleep() and friends is not OK for you, then the general thing to try is to do a delays not on every access, but, say, at each third access etc. Dosemu already does the like tricks for hogthreshold so in general this is feasible. >> What adlib engine are you using? The >> one currently inside dosemu is not >> intended to work at all. > The patch that is provided on your homepage. Ah, OK. Yes, it has problems, lots of problems. > It creates some noise that > sounds vaguely like the intended output, That varies from program to program. For example in Wolf3D the sound it produces is rather OK but in Dune it is pretty bad. The one disadvantage is that I have to drop the already filled buffers if the tone gen is suddenly reprogrammed, which produces a distortion. There might be other issues as well. > but it causes an extreme slowdown > in execution speed since the emulation code is implemented as extra > procedure inserted within the main program, Yes, this adlib engine is permanently broken in a polling mode. The problem is that we never know when some tone gen will be reprogrammed so we don't know how many data we can generate per a polling cycle. > the current patch seems to do with respect to the emulated opl), the program > running on real hardware simply writes data to the I/O ports and continues > execution while allowing the synth to process the data as a separate > entity. > Does that make sense? Of course. Threading looks like the only cure for adlib. Also the DMA can benefit from threading, but DMA works quite fine also in a polling mode because at least the buffer size is known (but I had to add a lot of heuristics about a buffer sizes to get it working acceptably in a polling mode so it would be better to put it in a separate thread as well). The problem is that somehow dosemu doesn't like pthreads. For example if I link it with -lpthread, at one point all the glibc functions starts to raise SIGSEGV with no apparent reason. On other machines it doesn't suck that bad but breaks DPMI, on some machines it works fine. This looks like a glibc-dependant problem and we don't know the solution (any glibc gurus around? :) I've been recently exploring the power of the Async IO and found it even more effective than threading in some particular cases http://sourceforge.net/tracker/index.php?func=detail&aid=689297&group_id=49784&atid=457449 but for adlib it doesn't look like a solution (if at all it can be applied to /dev/dsp). >> Surely you could find the card with >> even buggier third-party drivers, > Actually, probably not. :) OK, their aureal_re project looks promising, but it seems it advances with a speed of a turtle. >> will break recording (yeah, unlikely >> is used under dosemu, but anyway). > No problem, it can be tried to open O_RDWR first, and then O_WRONLY if > the first returns fd=-1. It is the problem however if it will do that silently so that the user will wonder why recording not always works. With the appropriate error message that looks acceptable. > No, the problem isn't multiple openings by dosemu itself, it's that if something > is already recording on the system, dosemu sound _playback_ won't even > work since the device open will fail. Yes I see. Most devices doesn't have the ability of a multiple opening even for output btw, so doing something with sound and using a dosemu for playback at the same time is a rare (but probably a usefull) thing. >> > 5) I'm working on VCPI and "unreal-mode" support. Someday, it will >> > happen. :) >> Optimist:) > Yea, we'll see. No, we'll not:( See the EMUfailures.txt:1.1