Trying to compile with Stas's sound patch

Trying to compile with Stas's sound patch

[Jan Willem Stumpel]

I'd like to try Stas's patch but cannot manage the compile. Could 
use a little help..

1) svn co https://svn.sourceforge.net/svnroot/dosemu/trunk dosemu
    succeeds, creates a directory ~/dosemu with the source code.
2) patch -p0 <dosemu-sound-21.diff also succeeds, without errors.
3) cd dosemu
4) autoheader produced the message:

    configure.ac:473: warning: AC_CONFIG_SUBDIRS: you should use
    literals
    autoconf/status.m4:929: AC_CONFIG_SUBDIRS is expanded from...
    configure.ac:473: the top level

    A similar warning came from autoconf. I do not know if this is
    serious.
5) ./default-configure -d seems to go OK.
6) "make" stops after the following error:

    In file included from oss.c:21:
    seqops.h:13: error: static declaration of ‘seqbuf_dump’ 
follows
    non-static declaration
    /usr/include/linux/soundcard.h:1057: error: previous
    declaration of ‘seqbuf_dump’ was here
    make[2]: *** [oss.o] Error 1
    make[2]: Leaving directory
    `/home/jws/dosemu/src/arch/linux/dosext/sound/midid'
    make[1]: *** [arch/linux/dosext/sound/midid] Error 2
    make[1]: Leaving directory `/home/jws/dosemu/src'
    make: *** [default] Error 2

uname -a is

Linux vega 2.6.15 #8 PREEMPT Fri Jun 23 13:44:05 CEST 2006 i686 
GNU/Linux

BTW such a pity that development has stopped.

Regards, Jan


-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jan Willem Stumpel]

I could compile by just changing the declaration of seqbuf_dump to 
static void in /usr/include/linux/soundcard.h.

It works very well, for example music in wolf3d and duke3d, and 
the old Soundblaster utilities now also work. It seems to use a 
lot of CPU, though.

Regards, Jan

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

[Jan Willem Stumpel]

(I thought I sent this a week ago, but just found out it was still
in "drafts"):

Stas Sergeev wrote:
> Hello.

> Aren't you symlinking /usr/include/linux to
> /usr/src/linux/include/linux by any chance?

Definitely not.

> Anyway, I added the hack that does what you say,
> and uploaded the patch. 

I'll try it.

>> 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. 

An example is the old Soundblaster utility fmorgan, which now
works with your patch (for which great thanks). It uses very
little cpu in dosbox and a lot in dosemu. On the other hand, the
"intro" music in Wolf3d does NOT use a lot of cpu in dosemu.
Technical explanations would probably be wasted on me.

Regards, Jan

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

[Stas Sergeev]

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.