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.
The patch that is provided on your homepage.What adlib engine are you using? The one currently inside dosemu is not intended to work at all.
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).
Actually, probably not. :)Surely you could find the card with even buggier third-party drivers,
OK, their aureal_re project looks promising, but it seems it advances with a speed of a turtle.
will break recording (yeah, unlikelyNo problem, it can be tried to open O_RDWR first, and then O_WRONLY if the first returns fd=-1.
is used under dosemu, but anyway).
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. :)Yea, we'll see.
Optimist:)
No, we'll not:( See the EMUfailures.txt:1.1
- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
