Re: XMS problem with Aladdin demo

[Stas Sergeev <stsp@aknet.ru>]

Hello.

Ryan Underwood wrote:
> What are the requirements of a new
> sound system, from your experience
> with the current one?
The main requirement is that it must
not access the OS sound driver (OSS
or ALSA) directly, like it does now.
There must be mid-layers in-between,
like at least resampling and mixing.
This may be done by the use of some
sound server, but most "low-end" sound
servers do not support the variable
sampling rate, i.e. you can't change
the rate without re-connecting to the
server. Other servers have the
unacceptable latencies.
There are now appearing those modern
sound servers like JACK, which probably
can satisfy our needs, but I haven't
looked into that.
Now that SDL is usually linked in to
dosemu, we can do the mixing/resampling
ourselves as well, and send the output
to SDL too. But SDL doesn't even
provide the ability to query the output
buffer status (the last time I looked),
which is not very good. Though using
SDL for sound looks attractive.
Another thing that have to be changed,
is that the SB emulator have to control
the rate itself, not like it does now -
write to the device until the buffer
is full. Some DOS progs controls the
DMA registers during the sound output,
and that's why we have to guarantee the
smooth transfer and the accurate timing
ourself. For that matter it will probably
be necessary to put the SB and DMA into
a separate thread. But then we also need
a mechanism to make sure our timing is
not out of sync with the underlying device,
and so we have to query the state of the
output buffer and adjust our speed according
to its state. It is probably not easy
to provide an accurate info about the
state of the buffers for the output
software that does the stream mixing,
like SDL, so AFAIK SDL doesn't provide
that info at all.
This all will also require a major
changes in the SB and DMA emulators, as
now they are too OSS-oriented. For example,
to change the speed, currently the sound
code waits for the OSS buffer to became
empty, resets the sound card, sets the
new parameters, and resumes the transfer.
It is obvious to see how difficult and
ineffective it is, and it is really a
big surprise that it works out right most
of the time. Well, thats because I added
a tons of heuristic about choosing an
optimal buffer sizes, tuned it separately
to a hundreds of games, etc. What a
silly timewasting it was, but at the time
of doing this, dosemu was not compatible
with pthreads, and the "good enough"
sound servers were not even on a horizon
(or at least I wasn't able to find them).
And I also followed the old code that
was there since 1995, instead of just
rewrite everything.
Now it may be wise to finally rewrite
everything from scratch, rather than
hacking with the current code. The fact
that it actually happens to work, must
not confuse anyone.
It may not be difficult to implement,
but only if the architecture is properly
designed. Otherwise it will be just
another time-wasting. That's why
noone even dare to start the work:)