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. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
