Re: App database, libsynth

Stas Sergeev
2003-07-13T19:50:05Z

Hello.

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 application
>> that 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".

>>> So the "compatibility mode" is only good for running
>>> the 32-bit applications while in longmode. Correct?
>> No: 16 bit is also OK.
> But not 16-bit realmode applications or 32-bit ring0
> applications either?
Seems like that.

> 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:)