From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ryan Underwood" Subject: Re: various dosemu comments and hacks (sound, delays) Date: Mon, 24 Feb 2003 15:46:19 +0000 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <20030224154620.80A9075370@mail.icequake.net> References: <3E5A2E23.5010006@yahoo.com> Mime-Version: 1.0 Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Stas Sergeev Cc: linux-msdos@vger.kernel.org Hi, > > for (i = 0; i < bogo; i++); > Busy loops?? I guess we have a better > ways to do delays (oh, probably a > precision of that other methods is > bad, but I guess the busy loops is a > bad thing to do). I know busy loops suck, but I wanted to illustrate that putting delays in those places (regardless of the nature of the delay) is something that can be used as a smooth speed throttle. :) If you can come up with a better delay, be my guest. > > 3) The Adlib emulation is not working well on my machine. > 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. It creates some noise that sounds vaguely like the intended output, but it causes an extreme slowdown in execution speed since the emulation code is implemented as extra procedure inserted within the main program, as opposed to a thread or separate process. > detect the adlib) so where does it go > blocking? In this case, what I mean by "Blocking" is simply that the adlib code is executed in sequence and the rest of dosemu is halted until it is finished. A separately scheduled process would seem to model the behavior of the real hardware more precisely; instead of the program stopping and waiting for the synthesizer chip to process the data and play the sound (which is what 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? > > On my Aureal AU8830, when a new DMA > > buffer is "loaded" and begins playing, I hear a click or pop, but > > nothing after that point. > Surely you could find the card with > even buggier third-party drivers, Actually, probably not. :) > but > at least you could visit the project > page and dig the patches section:) > http://sourceforge.net/tracker/index.php?func=detail&aid=680632&group_id=8109&atid=308109 Hmm, Feb 03... Guess I'll check that one out. :) (This patch wasn't there when I went loooking for fixes at first last month) > > In order to get this far, however, I had to change > > the two opens of /dev/dsp from O_RDWR to O_WRONLY. > In general this is not a solution, it > 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. > > The AU8830, like some other > > cards, only allows one application at a time to open the device for > > reading. > > Subsequent attempts at opening for read causes driver to return > > -ENOMEM. > I don't think dosemu opens it more than > once at a time. Yeah, but it's already opened by another application I am using (liveice). > > he offending opens are in linux_sb_get_version() and > > linux_sb_enable_speaker() > > in src/arch/linux/dosext/sound/linux_sound.c. > Note that linux_sb_get_version() closes > /dev/dsp right after opening, so only > the linux_sb_enable_speaker() really > keeps it opened, so there must be no > multiple openings in O_RDWR mode (at > least not intended to be). 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. > > 5) I'm working on VCPI and "unreal-mode" support. Someday, it will > > happen. :) > Optimist:) Yea, we'll see. Thanks! -- Ryan Underwood, , icq=10317253