well if the cd is stored as audio tracks on the cdrom then you need to mount your cdrom properly.
(and get the cvs version of both dosbox and libsdl.)
as there were some bugs in opening audiotracks under linux.

Thanks for your quick reply. Weirdly, though, I can't tell how the audio is stored-- I had already looked for it and there are no noticeable "audio" files on the CD. Here's the list of files:

dr-xr-xr-x 1 root root 2048 Nov 9 1996 .
drwxr-xr-x 4 root root 120 Oct 27 2004 ..
-r-xr-xr-x 1 root root 1528560 Oct 3 1996 acroread.exe
-r-xr-xr-x 1 root root 107 Dec 3 1992 adl.drv
-r-xr-xr-x 1 root root 19174309 Sep 18 1996 brdemo.exe
-r-xr-xr-x 1 root root 967 Sep 16 1996 brdemo.pif
dr-xr-xr-x 1 root root 2048 Nov 9 1996 bright
dr-xr-xr-x 1 root root 2048 Nov 9 1996 directx
-r-xr-xr-x 1 root root 20992 May 27 1996 dsetup.dll
-r-xr-xr-x 1 root root 34400 May 26 1996 dsetup6e.dll
-r-xr-xr-x 1 root root 34288 May 30 1996 dsetup6j.dll
-r-xr-xr-x 1 root root 41984 May 27 1996 dsetupe.dll
-r-xr-xr-x 1 root root 41984 May 30 1996 dsetupj.dll
-r-xr-xr-x 1 root root 1486774 Jun 11 1993 frp.sx
-r-xr-xr-x 1 root root 116 Dec 3 1992 genmidi.drv
-r-xr-xr-x 1 root root 1543 Mar 7 1994 inn.bat
-r-xr-xr-x 1 root root 174860 May 10 1993 install.exe
-r-xr-xr-x 1 root root 17555 Nov 20 1992 install.hlp
-r-xr-xr-x 1 root root 3188 Mar 11 1994 install.scr
-r-xr-xr-x 1 root root 9436 Apr 26 1993 install.txt
-r-xr-xr-x 1 root root 11562652 Mar 8 1994 krondor.001
-r-xr-xr-x 1 root root 456048 Mar 21 1994 krondor.nhb
-r-xr-xr-x 1 root root 545 Mar 2 1994 krondor.pif
-r-xr-xr-x 1 root root 14165 Mar 8 1994 krondor.rmf
-r-xr-xr-x 1 root root 43434065 Sep 23 1996 krondorm.pdf
-r-xr-xr-x 1 root root 2226 Oct 22 1996 language.inf
-r-xr-xr-x 1 root root 109 Dec 3 1992 mt32.drv
-r-xr-xr-x 1 root root 8758 Mar 8 1994 readme
-r-xr-xr-x 1 root root 19 Jun 16 1993 readme.bat
-r-xr-xr-x 1 root root 9856 Oct 25 1996 readme.wri
-r-xr-xr-x 1 root root 177 Feb 25 1994 resource.cfg
-r-xr-xr-x 1 root root 32336 Jul 21 1996 setup.exe
-r-xr-xr-x 1 root root 568257 Oct 3 1996 setup.sol
-r-xr-xr-x 1 root root 3181 Oct 30 1996 sierra.inf
-r-xr-xr-x 1 root root 97 Dec 3 1992 sndblast.drv
-r-xr-xr-x 1 root root 334605 Jul 28 1993 startup.gam
-r-xr-xr-x 1 root root 118 Dec 3 1992 std.drv
-r-xr-xr-x 1 root root 40742 May 5 1993 sx.ovl
dr-xr-xr-x 1 root root 2048 Nov 9 1996 vfw
-r-xr-xr-x 1 root root 44582 Oct 7 1992 vmcode.ovl
-r-xr-xr-x 1 root root 3170 Jul 31 1987 what.exe
-r-xr-xr-x 1 root root 17719440 Mar 9 1994 zzz.pad

The vfw folder is (unsurprisingly) for Video for Windows, I suppose, and is (surprisingly) empty-- if you've ever used this version (as opposed to the downloadable version), the deal was that there was a Windows Sierra installer, that you could run to install the game in Windows (95, I think), or you could install from DOS, so it makes sense for the vfw to be there.

The bright folder is the installer for the Birthright demo, which was in the pipeline at the time and was offered to install if you ran the Windows installer , and the directx folder is obvious.

So where the music is, or what format it's in, is a complete mystery; I guess it must be compressed in one of the krondor.* files, but that's no help.

Gentoo doesn't use -devel files, but I actually installed libSDL unstripped (because another, native, game won't show movies unless libSDL isn't stripped the way it is by most distributions), so all the headers and whatnot should be there.

As far as I can tell, the CD-ROM drive is mounted correctly; the file created by DOSBoxFE (dosbox_Betrayal at Krondor_.conf_curr) has at the end

[autoexec]
mount c /usr/local/games

[autoexec]
mount d /mnt/cdrom -t cdrom

and the CD is listable from DIR within DOSBox.

I'll try the CVS version, but looking at the cmd output of DOSBoxFE, I do now see some items of concern that I don't know how to fix:

"can't open device:oss with config:." (the only reference to OSS that I see is in the MIDI settings, and I'm feeling more and more sure that this is MIDI music)

"Can't open sequencer" (that's the device the MIDI has to be passed to, for virtual MIDI isn't it? I don't have a real MIDI device)

So I'm thinking that my problem is partially or fully that I don't have a MIDI device being found or created. I've got several MIDI-related modules (snd_rawmidi, snd_virmidi, snd_mpu401_uart, snd_seq_midi_event, which is connected to snd_seq_oss) loaded, and the TiMIDIty++ server running, so why there is no MIDI device I do not know. But if that's the issue, it's not so much a DOSBox problem anymore.

So three questions, then:

1) Do any Linux-based users have the CD version of BAK running, with music, and if so, how did you do that?

2) Is the CVS version likely to have an effect on this issue (does it handle... I dunno, decompression of files, or MIDI detection differently)? If not, I'll leave off installing it for a bit.

3) Is there any detailed DOSBox sound configuration tutorial, as I'm also wondering if my SB settings might not be wrong. But I don't know what IRQ and DMA to choose for SB emulation, as I can't really tell if these IRQs and DMAs (especially the DMAs) are being used for some other (real) settings, and perhaps there's a conflict which is causing the sound I am getting to degrade.

OK, I've thought of at least two things more to tinker with on my end; maybe it will help.

Thanks for helping me work my way through this.

I haven't tried running the CD version of BAK with DOSBox (mostly because the only advantage IMO is being able to have both digitized sounds and better-than-OPL music at the same time), but I do know that the music is stored on the CD as standard Redbook CD-DA audio tracks.

Note that MIDI is not used by the CD version of B@K because it uses the music tracks on the CD.

As for CVS, it's always good to try the latest stuff you can get your hands on, especially with apps like DOSBox whose official releases are...infrequent.

HunterZ wrote:

but I do know that the music is stored on the CD as standard Redbook CD-DA audio tracks.

I bow to your superior knowledge, but why can't I see said tracks on the CD, either in DOSBox or in a file manager (Krusader)? That seems odd.

Anyway, I've finally got a MIDI device (/dev/midi, though, not /dev/midi00)-- even if that isn't relevant, and I'm compiling the CVS now and hoping it's correct (Gentoo actually has a dosbox-cvs ebuild, but for some reason it's called dosbox-cvs-20030809, despite the fact that it looks like a perfectly normal CVS checkout, so I'm a bit confused by that).

We'll see if maybe that helps; hope it does.

You can't see the tracks because DOS and most other operating systems only see the data track (track 1 on most mixed data+audio CDs) that contains an ISO9660 filesystem with the game files on it. The audio tracks are totally separate tracks that are external to the filesystem track, so they will be totally ignored by the operating system unless a game or CD audio player tells it to look for them. In fact, it used to be that the operating system had no way of reading the audio tracks at all, and games used to ask the CD-ROM drive to play the audio tracks just like a car or home stereo CD player would and send the audio to the sound card via an audio cable inside the computer connecting the two devices.

Anyways, I'm not actually sure if DOSBox supports CD-audio (never tested it), but I expect that it does. You might need to use the fancy -usecd parameter when mounting the CD drive in DOSBox: http://dosbox.sourceforge.net/wiki/index.php? … M+does+not+work

Under linux, most CD playing programs should play the audio tracks off your CD (I personally use gnome-cd myself for mixed-mode CDs) If you're really at a loss for how to test it, I personally recommend the CDfs kernel module.

http://www.elis.rug.ac.be/~ronsse/cdfs/

When you mount a CD using this filesystem, it will display all audio tracks as wave files, data tracks as .iso images, and video CD movies as .mpegs

well to acces audiotracks you need to mount
mount d /cdrom -t cdrom -ioctl -usecd #

# found by mount -cd

but this was a bit broken sometimes on both dosbox and sdl.

if you have a recent version of sdl (really recent)
you can omit the -usecd # and hope it works (as that works around the dosbox bug).

else make a cdrom iso of it (cue/bin as it's more than one track) and mount that using imgmount.

Update: I tried using the mount d /mnt/cdrom -t cdrom -ioctl -usecd option; didn't seem to help. I then turned off CD Music in the game options, and the regular music played. It stuttered so bad it was pretty unrecognizeable, but it played, and the slowdown was probably at least partially caused by other operations on my system at that moment; when they're done, I'll turn everything off and see if it improves.

As for trying to play the CD "normally" via a CD player... well, GnomeCD froze up and crashed out when I tried that. I got a "not responding" window to close the program, though, so that definitely suggests a problem with either my CD (it is old, after all), and/or my audio CD playing facilities or both. I rarely (almost never) play audio CDs on my PC, so it's quite possible that support for them is missing or incomplete, plus I'm trying to run GnomeCD under KDE, plus my DVD-RW is mounted using the subfs fs, which I have little experience with (but I could see how audio CDs might not get along with it).

And this does begin to seem familiar... istr that under Windows (95/98) that if there was something wonky about MSCDEX (wrong parameters, whatever), that I would have similar issues (despite CD music being checked, it would not play, though I don't remember if nothing at all played).

So at this point, I assume it's a misconfiguration or conflict in my backend, and that once that's cleared up, DOSBox should be happier at default settings.

In the meantime, can I reasonably hope that reducing my CPU cycles will have an effect on the sound stuttering and distortion? I've got it currently set at 19500/2 which runs the game at a pretty nice speed, even at fullscreen. I based this on some other post here using an Athlon XP 3000, but naturally that is probably asking too much of my Athlon XP 2200+. I'm only asking (rather than just trying) because it'll take a bit for this compile to finish, so there's no point in trying to judge available CPU cycles when the CPU is being used by Portage. Any ballpark figure for a reasonable compromise setting would be appreciated. Or is the problem more likely in my SB emulation settings (though changing them didn't seem to have any effect in previous trials)?

And btw, despite these "problems", it really is terrific (understatement) to be able to play BaK again (not your fault if I'm greedy)-- thank you, thank you, thank you!!!

QBix: -ioctl is meaningless for him, since he's running Linux.

motub: Sound stuttering in DOSBox usually indicates that your cycles are set too high and the CPU is getting taxed too hard.

As for the CD audio, it does sound like you might have other kinks to work out. Qbix' idea of ripping the CD to an ISO image, audio tracks and all, sounds like it might help for you.

HunterZ wrote:

QBix: -ioctl is meaningless for him, since he's running Linux.

Yes, I thought that's what the Wiki said. Thanks for the confirmation.

Oh, and just for completeness, it's "she" 😏 .

And that's the end of my smugness, as I've just been bludgeoned by the blindingly obvious.... So I installed KsCD, and this didn't crash when trying to play the CD audio. It was playing, but I didn't hear anything.

Enter the blindingly obvious... Went to the KsCD settings, set "use digital output", and (of course) the CD then played "fine" (a bit of hitching because I'm still compiling, but it was playing).

This means I have to reconnect the analog output cable between my DVD-RW and my sound card, doesn't it? Assuming that I even have connectors on the card (it's new; haven't checked).

But DOSBox doesn't support digital output, does it? Can't see why it would, since DOS doesn't. I feel really really stupid for not catching this, but I think that might be the root of the issue. Am I mistaken?

HunterZ wrote:

motub: Sound stuttering in DOSBox usually indicates that your cycles are set too high and the CPU is getting taxed too hard.

OK. So at this point, I need to 1) either reconnect the analog audio cable or learn/be told any possibly existing DOSBox setting that will enable digital audio, and 2) reduce my cycles, and I should be fine, yes?

Holly

about ioctl

it's used by default when you use a -usecd term. (linux is all about ioctls)
but -usecd is broken in the current version of dosbox + libsdl.

This is also the reason why you don't hear the music inside dosbox.
it are audiotracks and those must be played using the -ioctl interface.
which is the default mode of the -usecd interface. which is broken
in the current version of dosbox +sdl.

if you feel very ambigous get the latest cvs source of both and try.

Qbix: By current version do you mean the 0.63 release?

motub: I think Qbix is saying that if you use builds of the latest DOSBox and SDL CVS sources, the -ioctl thing should make CD Audio in DOSBox work. I don't know if it will use digital or analog playback though.

Let us know if you get it working or run into more problems - I'm curious about it now...

Update #2:

As of this moment, the only thing not working is the CD audio. The regular audio is working perfectly and the game is running at a good speed. Plus, CD audio has unchecked itself in the game Preferences, and if I do check it, it re-unchecks itself. This is a good thing, as it means that the game is communicating properly with itself, or the CD drive or whatever. In any case, this is behaviour I remember, as opposed to the previous behaviour I was seeing, where CD Music 1) remained checked and 2) disabled the regular music (I got regular, choppy, music if I disabled CD music, but this setting did not persist).

This is a result of tweaking around with the CPU cycles (8000), frameskip (the full 10, but that may not be necessary), and the SB emulation settings (went to sbpro1, ramped up the mix rates to 44100 for everything and set the MIDI device to alsa, since that's where my shiny new MIDI is detected, and turned on MPU401).

As of now, I'd say this runs exactly like the download version of BAK did under Win98, so even if I can't get CD audio working, I'm still very, very happy. Thank you both again for your help and your work in creating this wonderful product.

But in the name of science 😉 , I'll see if I can get CD audio working.

I'd prefer not to use the CVS version of libSDL if I can avoid it, so I'll start with just the CVS version of DOSBox and see if that gets me any further, as libSDL-1.2.8-r1 is compiled unstripped, as is sdl-sound. I also compiled sdl-sound with physfs and speex support that it hadn't had before. Gentoo tends to add upstream patches if available, so the ioctl issue may be patched in my current install, for all I know, and I've got enough stuff installed that depends on libSDL and its children that I really don't want to rework my whole SDL setup if I don't have to.

I've downloaded the zipped CVS tarball from CVS-Compile, which is updated daily, so should be current. If this is not the case, please let me know and I'll do the real CVS checkout thing.

Otherwise, we'll see how far I get, and I'll keep you posted.

Holly

I'm not sure how often that zip file is updated, but if it's as old as the binary on there then it should be fine, as there haven't been any CD-related updates to the DOSBox CVS in a while. Unfortunately, that probably also means that it isn't likely to help you much.

Btw, how fast is your CPU? Have you tried using the dynamic core in DOSBox?

It's an Athlon XP 2200+, so about 1.8Mhz. Yes, I did try the dynamic core, and dropped back down to the normal, but I may go back. But speed is not a problem.

From what I can tell, the CVS-Compile tarball is as current as it can be (it says they update daily, the changelog goes to May 3 and the files seem to be from yesterday or today depending on what time I downloaded it)... but unfortunately it won't compile.

Actually, it won't configure. I ran autogen.sh, which gave me a warning before completing successfully (so it said):

1# ./autogen.sh
2Generating build information using aclocal, autoheader, automake and autoconf
3This may take a while ...
4/usr/share/aclocal/xdelta.m4:7: warning: underquoted definition of AM_PATH_XDELTA
5  run info '(automake)Extending aclocal'
6  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
7/usr/share/aclocal/wxwin.m4:36: warning: underquoted definition of AM_OPTIONS_WXCONFIG
8/usr/share/aclocal/wxwin.m4:59: warning: underquoted definition of AM_PATH_WXCONFIG
9/usr/share/aclocal/sdlmm.m4:12: warning: underquoted definition of AM_PATH_SDLMM
10/usr/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES
11/usr/share/aclocal/oaf.m4:4: warning: underquoted definition of AM_PATH_OAF
12/usr/share/aclocal/movtar.m4:14: warning: underquoted definition of MOVTAR_TEST_VERSION
13/usr/share/aclocal/movtar.m4:59: warning: underquoted definition of AM_PATH_MOVTAR
14/usr/share/aclocal/libreiser4.m4:14: warning: underquoted definition of AC_CHECK_LIBREISER4
15/usr/share/aclocal/libglade.m4:7: warning: underquoted definition of AM_PATH_LIBGLADE
16/usr/share/aclocal/libfame.m4:6: warning: underquoted definition of AM_PATH_LIBFAME
17/usr/share/aclocal/libart.m4:11: warning: underquoted definition of AM_PATH_LIBART
18/usr/share/aclocal/libaal.m4:14: warning: underquoted definition of AC_CHECK_LIBAAL
19/usr/share/aclocal/libIDL.m4:6: warning: underquoted definition of AM_PATH_LIBIDL
20/usr/share/aclocal/imlib.m4:9: warning: underquoted definition of AM_PATH_IMLIB
21/usr/share/aclocal/imlib.m4:167: warning: underquoted definition of AM_PATH_GDK_IMLIB
22/usr/share/aclocal/gtkgl.m4:4: warning: underquoted definition of AM_PATH_GTKGL
23/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
24/usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
25/usr/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted definition of AM_PATH_GDK_PIXBUF
26/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
27/usr/share/aclocal/ORBit.m4:4: warning: underquoted definition of AM_PATH_ORBIT
28configure.in: installing `./install-sh'
29configure.in: installing `./missing'
30src/Makefile.am: installing `./depcomp'
31configure.in:8: installing `./config.guess'
32configure.in:8: installing `./config.sub'
33Makefile.am: required file `./ChangeLog' not found
34Now you are ready to run ./configure.
35You can also run  ./configure --help for extra features to enable/disable.

But given that it's "only" a ChangeLog, I went further with ./configure:

1 ./configure --enable-core-inline                      
2checking build system type... i686-pc-linux-gnu
3checking host system type... i686-pc-linux-gnu
4checking target system type... i686-pc-linux-gnu
5checking for a BSD-compatible install... /bin/install -c
6checking whether build environment is sane... yes
7checking for gawk... gawk
8checking whether make sets $(MAKE)... yes
9checking whether make sets $(MAKE)... (cached) yes
10checking for gcc... gcc
11checking for C compiler default output file name... a.out
12checking whether the C compiler works... yes
13checking whether we are cross compiling... no
14checking for suffix of executables... 
15checking for suffix of object files... o
16checking whether we are using the GNU C compiler... yes
17checking whether gcc accepts -g... yes
18checking for gcc option to accept ANSI C... none needed
19checking for style of include used by make... GNU
20checking dependency style of gcc... gcc3
21checking how to run the C preprocessor... gcc -E
22checking for g++... g++
23checking whether we are using the GNU C++ compiler... yes
24checking whether g++ accepts -g... yes
25checking dependency style of g++... gcc3
26checking for a BSD-compatible install... /bin/install -c
27checking for ranlib... ranlib
28checking for sdl-config... /usr/bin/sdl-config
29checking for SDL - version >= 1.2.0... yes
30checking for an ANSI C-conforming const... yes
31checking for inline... inline
32checking for egrep... grep -E
33checking for ANSI C header files... yes
34checking for sys/types.h... yes
35checking for sys/stat.h... yes
36checking for stdlib.h... yes
37checking for string.h... yes
38checking for memory.h... yes
39checking for strings.h... yes
40checking for inttypes.h... yes
41checking for stdint.h... yes
42checking for unistd.h... yes
43checking for size_t... yes
44checking whether struct tm is in sys/time.h or time.h... time.h
45checking for unsigned char... yes
46checking size of unsigned char... 1
47checking for unsigned short... yes
48checking size of unsigned short... 2
49checking for unsigned int... yes
50checking size of unsigned int... 4
51checking for unsigned long... yes
52checking size of unsigned long... 4
53checking for unsigned long long... yes
54checking size of unsigned long long... 8
55checking for int *... yes
56checking size of int *... 4
57checking if environ can be included... no
58checking if environ can be linked... yes
59checking if compiler allows __attribute__... yes
60checking if compiler allows __builtin_expect... yes

61checking for ALSA CFLAGS... 
62checking for ALSA LDFLAGS...  -lasound -lm -ldl -lpthread
63checking for libasound headers version >= 0.9.0... found.
64checking for snd_ctl_open in -lasound... yes
65checking whether byte ordering is bigendian... no
66enabling inlined memory handling in CPU Core
67checking for target cpu type... x86 compatible
68checking whether x86 dynamic cpu core will be enabled... yes
69checking whether fpu emulation will be enabled... yes
70checking whether x86 assembly fpu core will be enabled... yes
71checking whether to enable unaligned memory access... yes
72checking png.h usability... yes
73checking png.h presence... yes
74checking for png.h... yes
75checking for png_check_sig in -lpng... yes
76checking SDL_net.h usability... yes
77checking SDL_net.h presence... yes
78checking for SDL_net.h... yes
79checking for SDLNet_Init in -lSDL_net... yes
80checking for main in -lGL... yes
81checking for main in -lopengl32... no
82checking GL/gl.h usability... yes
83checking GL/gl.h presence... yes
84checking for GL/gl.h... yes
85checking whether opengl display output will be enabled... yes
86checking SDL/SDL_sound.h usability... yes
87checking SDL/SDL_sound.h presence... yes
88checking for SDL/SDL_sound.h... yes
89checking for Sound_Init in -lSDL_sound... yes
90checking for Sound_Seek in -lSDL_sound... yes
91checking for setpriority support... yes
92configure: creating ./config.status
93config.status: creating Makefile
94config.status: error: cannot find input file: Makefile.in

and indeed, there is no Makefile.in, but only a Makefile.am . Not exactly being prepared to hack the configure file, this is where I'm stuck atm, but at least I can play with the regular (non-CD) music and sound effects (the birds finally sound normal again 😀 ).

I'm willing to continue trying to compile the CVS version, but someone will have to tell me what to do about this missing Makefile.in. I can barely write a bash script; configure files are completely out of my league.

http://pcnwstage.phys.rug.nl/dosboxcvs.tgz
use that source.

but it won't work without the fixed sdl as sdl seems(in 1.2.8 and lower) to cdrom devices in inclusive mode which doesn't mix with a mounted filesystem (mount on your linux host)

You can actually fix the sdl library in portage (at your own risk):

as normal user change to a temporary directory:
cd /tmp

extract the portage version of the SDL library (assuming you use libsdl-1.2.8-r1):
tar -xzvf /usr/portage/distfiles/SDL-1.2.8.tar.gz

remove the exclusive open flags from the cdrom stuff:
sed "s/|O_EXCL//g" SDL-1.2.8/src/cdrom/linux/SDL_syscdrom.c > tmp
mv tmp SDL-1.2.8/src/cdrom/linux/SDL_syscdrom.c

repackage and cleanup:
tar -czvf SDL-1.2.8.tar.gz SDL-1.2.8
rm -r SDL-1.2.8

now change to root and move the new package to distfiles:
mv /tmp/SDL-1.2.8.tar.gz /usr/portage/distfiles

generate new digest and finally emerge libsdl:
ebuild /usr/portage/media-libs/libsdl/libsdl-1.2.8-r1.ebuild digest
emerge libsdl

There is no need to recompile dosbox.

good one prompt !

but I changed something in the cdrom file of dosbox as well
http://cvs.sourceforge.net/viewcvs.py/dosbox/ … r1=1.18&r2=1.19

as we didn't open the cdrom when in forced mode.
it was only done in the loop which looked for the mountpoint corresponding with the cdrom.

thanks, qbix.
It worked before your change too, probably because the cdrom is opened somewhere else as well.