various dosemu comments and hacks (sound, delays)
Hello.
Quoted 1 line · Ryan Underwood
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.
Quoted 4 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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).
Quoted 3 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
will break recording (yeah, unlikely is used under dosemu, but anyway).
No problem, it can be tried to open
O_RDWRfirst, and thenO_WRONLYif 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.
Quoted 2 lines
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.
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
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
hi,
Quoted 6 lines
Quoted 2 lines
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 ofusleep()
and friends is not OK for you,
The precision is not the problem as much as having the context switch time within every iteration of that loop is really bad for performance. e.g., even nanosleep(0) incurs a way too much performance hit. Try it and see if you have the same results as me.
Quoted 6 lines
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.
Ok, I'll try to make it a little better.
Quoted 5 lines
Quoted 5 lines
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?
Quoted 10 lines
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).
Ok.. my implementation is going to be with a separate process because I am developing adlib server for other reasons too, so my code will be re-usable.
The adlib server will either emulate the adlib card or pass through the writes to real OPL hardware (e.g., /dev/dmfm*). Alternately it could be done the other way around; have the client program (e.g. dosemu) write to /dev/dmfm, and depending on the driver that is installed, either the driver writes to real adlib hardware, or an emulation driver stub registers /dev/dmfm and forwards the writes to userspace emulation daemon, which then outputs to /dev/dsp.
Which way do you think is better?
Quoted 5 lines
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.
Hmm, what do you mean by "all the glibc functions"? There are many glibc functions that require re-entrant replacements to be used when threading is involved. Such as localtime()=>localtime_r() and the rest of the _r() functions. I'm sure you probably already know this, but it may have slipped past you.
Quoted 2 lines
I've been recently exploring the power of the Async IO
Interesting, will take a look at it.
Quoted 7 lines
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).
So, basically, it seems to be a non-blocking form of polling?
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
Surely you could find the card with
even buggier third-party drivers,Actually, probably not. :)
OK, their
aureal_reproject looks promising, but it seems it advances with a speed of a turtle.
Yeah, that's what happens when the company disappears without leaving us documentation. Well, they left documentation, but Creative has it at the bottom of a locked filing cabinet in a rarely used lavatory, it seems.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
will break recording (yeah, unlikely
is used under dosemu, but anyway).No problem, it can be tried to open
O_RDWRfirst, and thenO_WRONLYif 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.
Yeah, just S_printf("User with buggy sound driver, please let go of the sound device before running dosemu\n") or something similar :)
Quoted 6 lines
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.
Many PCI cards will support multiple opens, not the same for ISA unfortunately, you are correct.
Quoted 6 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
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
There are a few strategies I am exploring:
1) Search-and-destroy in the program image before execution, according to heuristics, or a provided lookup table. Relocate the bad memory writes and nop out unnecessary privileged instructions. This won't work in a variety of cases: program self-modifies, program depends on privileged instructions, etc. Un-realmode can be easily handled this way though because many of those programs don't use privileged instructions besides the initial switch in and out of protected mode. This is the way the U7-win9x patch works.
2) When supervisor instruction is encountered, trap the fault and sent the machine state to Bochs or other x86-emu. Let it run the privileged instruction(s) and/or priveleged state, and upon the program's return to v86, return the machine state to dosemu.
3) Translate VCPI calls to DPMI equivalents? Not sure how this would work, and again would only be valid if the program didn't run 386 ring 0 instructions at all.
I think #2 is the promising one, but it will be some work.
Signature · 1 line
Ryan Underwood, <nemesis at icequake.net>, icq=10317253