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

[Stas Sergeev <stssppnn@yahoo.com>]

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