Ryan Underwood wrote:
Just tried aoss. It didn't work too horribly on the ones
I tried (Duke3D, Hardball III). The sound warbles and there are lots of clicking, but overall it could be a lot
worse.
Better than I expected, at least a nonblocking IO is not a problem. But all that clicks and underruns you see are most likely due to an inaccurate buffer load reporting. It is difficult to report the "expected" buffer load after the resampling and mixing are performed.
Just to make sure, the PC speaker needs no programming besides writing to the two hardware ports, correct?
Which ones do you mean? There is only one port to control the speaker - 0x61. But one have to also program a PIT channel 0 and 2 to do the PWM, which uses 3 more ports. So you have to define the interface for client to provide the timestamps to your lib for the decoding.
Hmm, so what's the best way to use a OPL3-emulated sequencer from dosemu?
The *only* way I can think of, is simply passing the raw data that the app is writing to the OPL3 ports. Midi is an absolutely different thing here. Dosemu emulates the MPU-401 UART, so for midi it is able to produce the raw midi stream which can be interpreted by midid and passed to a sequencer (or handled internally by one of the midid plugins).
If I make it an ALSA client, people using midid will not be able to use it. If I make it a server application that midid talks to, it is less flexible for the people who could use it through ALSA applications.
There might be some misunderstanding. The OPL3 software synthesizer can be used in two ways: 1. It implements a sequencer interface *for midi*. The app (like midid) writes the midi messages to it, and the lib is trying to generate some music for them (yes, OPL3 is not very good for midi I would say, but I know several DOS midi players that can use OPL3 as an output device). This is good to have in general, but it has zero use for dosemu. Dosemu/midid can work with timidity, which does much better than an OPL3 synthesizer can do for midi. 2. It implements an OPL3 emulator, i.e. provides its ports and produces some sound output (or the midi output, like the bochs does IIRC). In this case only dosemu can use it, but then it will be used not for playing midi (which is done by timidity much better anyway), but rather for emulating the Adlib.
So:
If I make it an ALSA client, people using midid will not be able to use it.
You seem to be talking about the way (1) here. I am sure midid doesn't need to use your libsynth at all because it can use timidity. OTOH writing an alsa-alike plugin for midid is very easy because it will be much similar to midid's current timidity plugin.
If I make it a server applicationthat midid talks to, it is less flexible for the people who could use it through ALSA applications.
The same, midid doesn't need the libsynth at all, but it is very flexible and can mimic the alsa.
I could do both but that takes a lot of time. :)
I think you *have* to do both, otherwise your lib would be useless.
Overall I might be misunderstanding you, but it seems to me that you have confused the midi with an OPL synth, which are very different and orthogonal things. They have different code pathes inside dosemu and must have different pathes outside it. So essentially midid cannot be used for an OPL synth. In short: you can use OPL synth for emulating an Adlib, *or* as a midi sequencer (like timidity). For dosemu it is important to have an Adlib emulation, because the midi support is already in place, but you can do both.
is unlikely but not impossible: after all also X vesa driver uses it, and so does wine, so there might be some motivation after all...What does wine use it for?
Dos emulation:) Wine has an SB and DMA emulation for DOS progs even AFAIK.
I think XFree86 uses it for Int10 support too.Yes, that's what I reverred to as "X vesa driver".
Seems like that.But not 16-bit realmode applications or 32-bit ring0 applications either?So the "compatibility mode" is only good for running the 32-bit applications while in longmode. Correct?No: 16 bit is also OK.
Those VCPI-games should be taken care of like that too, Privateer, Strike Commander et.al.
I don't understand why the game would require a ring-0 access. I think that is a bad design so I wouldn't care too much about it. The authors must fix that games, use a proper extender or whatever. I hope there are not too much of those. But VCPI would be good to have after all:)
- 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
