Re: Trying to compile with Stas's sound patch (2)

[Stas Sergeev <stsp@aknet.ru>]

Hello.

Jan Willem Stumpel wrote:
> I could compile by just changing the declaration of seqbuf_dump to 
> static void in /usr/include/linux/soundcard.h.
Aren't you symlinking /usr/include/linux to
/usr/src/linux/include/linux by any chance?
Anyway, I added the hack that does what you say,
and uploaded the patch. You can now see the file
seqbuf.h which tries to insert the "static" keyword
in a few places of soundcard.h. Evil but should work.
Beware though that I've diffed my working tree this
time - in a state it was abandonned. I think it is
consistent and should work, but who knows. It looks
like it has a huge differences with the previously
uploaded patch.

> It works very well, for example music in wolf3d and duke3d, and 
> the old Soundblaster utilities now also work.
The goal of that "project" was to find out whether I
can emulate the hardware very precisely, yet keep it
simple and not to drown in the implementation details.
I think I've managed - that code is highly compatible
with the real SB16 and every piece of it is about 3-4
times smaller than of the old implementation.

> It seems to use a lot of CPU, though.
FM and the MIDI synth use a lot of CPU and there is nothing
to do with this. I have reduced the sampling rate of the FM
synth to 22050 and disabled most of the midi effects, yet it
is still quite CPU-hungry. You can't compare it with an old
code which simply didn't have the FM synths at all and did
use midid for midi. If you set up your DOS progs to not produce
the music but only the digital sound, then you can compare.
My code will still be more CPU-hungry but not noticeably.
The reason is that it does the intermidiate sound processing,
buffering, timing control and many more things which the old
code did not. There are always the quality vs performance
tradeoffs.