Re: various dosemu comments and hacks (sound, delays)

["Ryan Underwood" <nemesis-lists@icequake.net>]

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, <nemesis at icequake.net>, icq=10317253