James-F wrote:

Excellent work btw, I use Opus plenty, but not in dosbox yet.

I've enjoyed reading your audio-related posts. One of the benefits Opus adds to DOSBox is avoiding resampling along the software and audio hardware chain, because almost all modern DACs use 48kHz as their native rate.

If you set DOSBox's mixer rate to 48kHz in your dosbox-SVN.conf, and then mount your Opus+CUE, the patch ensures PCM samples are passed through at least up to the edge of the audio driver, at which point the samples should continue at 48kHz clean through the remaining digital HW chain.

Where as with 44.1kHz tracks, resampling to 48kHz will be performed (possibly poorly) at various points along the chain.

I haven't attempted to quantitize those losses compare to the pure-passthrough Opus scenario, but it would be interesting none the less!

James-F wrote:

@Yesterplay80
Do you still add patches manually or you use some script to apply them all and compile with one click?
I'd imagine it takes a lot of your time patching them one by one each new SVN.

When applying new or changed patches I apply them manually one by one, to see if and where they interfere or fail. If there are no new or changed patches or when all is fine or corrected, I just run a shell script written by me in MinGW which applies them, compiles the binaries, zips them and uploads them on my Google Drive. I just check the output for errors.

krcroft wrote:

I've updated the FLAC-Opus-MP3 patch to rev5, posted here:
AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks

This part of the patch is unnecessary since r4173 because Qbix commited this change to the source code:

1diff -x gui_tk -x zmbv -x '.git*' -x scripts -Naur src/dos/drives.cpp src/dos/drives.cpp
2--- src/dos/drives.cpp	2018-07-10 14:10:03.000000000 -0700
3+++ src/dos/drives.cpp	2018-11-17 12:38:12.016636474 -0800
4@@ -132,7 +132,7 @@
5 		driveInfo.currentDisk = 0;
6 		DOS_Drive* disk = driveInfo.disks[driveInfo.currentDisk];
7 		Drives[currentDrive] = disk;
8-		disk->Activate();
9+		if (driveInfo.disks.size() > 1) disk->Activate();
10 	}
11 }
12 

Yesterplay80 wrote:

This part of the patch is unnecessary since r4173 because Qbix commited this change to the source code: […]
Show full quote

This part of the patch is unnecessary since r4173 because Qbix commited this change to the source code:

Copy code to clipboard

1diff -x gui_tk -x zmbv -x '.git*' -x scripts -Naur src/dos/drives.cpp src/dos/drives.cpp
2--- src/dos/drives.cpp	2018-07-10 14:10:03.000000000 -0700
3+++ src/dos/drives.cpp	2018-11-17 12:38:12.016636474 -0800
4@@ -132,7 +132,7 @@
5 		driveInfo.currentDisk = 0;
6 		DOS_Drive* disk = driveInfo.disks[driveInfo.currentDisk];
7 		Drives[currentDrive] = disk;
8-		disk->Activate();
9+		if (driveInfo.disks.size() > 1) disk->Activate();
10 	}
11 }
12 

Thanks for the heads up; will snip that from my side so it won't appear in the next revision.

I'm using Slackware Linux 14.2 and getting an error when compiling r4173. This is the first version that has failed to compile on my system.

1g++ -DHAVE_CONFIG_H -I. -I../../..  -Iinternal/ogg/include -Iinternal/opus/include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT  -Wall -g -O2 -mno-ms-bitfields  -MT libdecoders_a-mp3.o -MD -MP -MF .deps/libdecoders_a-mp3.Tpo -c -o libdecoders_a-mp3.o `test -f 'mp3.cpp' || echo './'`mp3.cpp
2mp3.cpp: In function ‘void load_seek_table(Sound_Sample*, std::vector<unsigned int>&)’:
3mp3.cpp:229:46: error: no matching function for call to ‘std::basic_ifstream<char>::basic_ifstream(std::string&, const openmode&)’
4         ifstream infile(filename, ios::binary);
5                                              ^
6In file included from mp3.cpp:30:0:
7/usr/include/c++/5.5.0/fstream:495:7: note: candidate: std::basic_ifstream<_CharT, _Traits>::basic_ifstream(const char*, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>; std::ios_base::openmode = std::_Ios_Openmode]
8       basic_ifstream(const char* __s, ios_base::openmode __mode = ios_base::in
9       ^
10/usr/include/c++/5.5.0/fstream:495:7: note:   no known conversion for argument 1 from ‘std::string {aka std::basic_string<char>}’ to ‘const char*’
11/usr/include/c++/5.5.0/fstream:481:7: note: candidate: std::basic_ifstream<_CharT, _Traits>::basic_ifstream() [with _CharT = char; _Traits = std::char_traits<char>]
12       basic_ifstream() : __istream_type(), _M_filebuf()
13       ^
14/usr/include/c++/5.5.0/fstream:481:7: note:   candidate expects 0 arguments, 2 provided
15/usr/include/c++/5.5.0/fstream:455:11: note: candidate: std::basic_ifstream<char>::basic_ifstream(const std::basic_ifstream<char>&)
16     class basic_ifstream : public basic_istream<_CharT, _Traits>
17           ^
18/usr/include/c++/5.5.0/fstream:455:11: note:   candidate expects 1 argument, 2 provided
19mp3.cpp:284:60: error: no matching function for call to ‘std::basic_ofstream<char>::basic_ofstream(std::string&, std::_Ios_Openmode)’
20         ofstream outfile(filename, ios::trunc | ios::binary);
21                                                            ^
22In file included from mp3.cpp:30:0:
23/usr/include/c++/5.5.0/fstream:697:7: note: candidate: std::basic_ofstream<_CharT, _Traits>::basic_ofstream(const char*, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>; std::ios_base::openmode = std::_Ios_Openmode]
24       basic_ofstream(const char* __s,
25       ^
26/usr/include/c++/5.5.0/fstream:697:7: note:   no known conversion for argument 1 from ‘std::string {aka std::basic_string<char>}’ to ‘const char*’
27/usr/include/c++/5.5.0/fstream:682:7: note: candidate: std::basic_ofstream<_CharT, _Traits>::basic_ofstream() [with _CharT = char; _Traits = std::char_traits<char>]
28       basic_ofstream(): __ostream_type(), _M_filebuf()
29       ^
30/usr/include/c++/5.5.0/fstream:682:7: note:   candidate expects 0 arguments, 2 provided
31/usr/include/c++/5.5.0/fstream:656:11: note: candidate: std::basic_ofstream<char>::basic_ofstream(const std::basic_ofstream<char>&)
32     class basic_ofstream : public basic_ostream<_CharT,_Traits>
33           ^
34/usr/include/c++/5.5.0/fstream:656:11: note:   candidate expects 1 argument, 2 provided
35Makefile:504: recipe for target 'libdecoders_a-mp3.o' failed
36make[4]: *** [libdecoders_a-mp3.o] Error 1

It looks like my c compiler is missing some functions needed to build libdecoders_a-mp3. My gcc version is 5.5.0, the most recent for Slackware 14.2, released during Feb 2018. There is an 8.2.0 in the -current repo but it's bad to mix -current with the stable 14.2

Dracolich wrote:

It looks like my c compiler is missing some functions needed to build libdecoders_a-mp3. My gcc version is 5.5.0, the most recent for Slackware 14.2, released during Feb 2018. There is an 8.2.0 in the -current repo but it's bad to mix -current with the stable 14.2

Dracolich, sorry for the hassle, and thanks for the report! I tried reproducing the issue by installing GCC 5.5 and 4.9 (using pacaur on an ARCH system), but unfortunately both compilers built it clean. I've made two changes to the fstream instantiations: switched to using std::ios_base, and to using const char* instead of std::string's (thanks Qbix).

Would you be able to try another build with the update? If it runs clean for you then we can recommend the improvement to Yesterplay80.

1. Download the baseline DOSBox r4173 source from: http://source.dosbox.com/dosboxsvn.tgz
2. Download the updated patch: download/file.php?id=55658
3. Sitting into your extracted dosbox source directory, run: zcat /path/to/dosbox-r4173-internal_codecs-rev7.patch.gz | patch -p1
4. Build as usual: ./autogen.sh && ./configure && make -j $(nproc)

judging from the error, without looking at the error, isn't just a .c_str() needed to the infile ?
I might be wrong as without looking at the code, I could be thinking of the wrong thing.

Qbix wrote:

judging from the error, without looking at the error, isn't just a .c_str() needed to the infile ?
I might be wrong as without looking at the code, I could be thinking of the wrong thing.

Thanks for the closer inspection Qbix, I think you're right as well after double checking the error. I've switched to pure const char*'s.

Dracolich, I've update the patch to 'rev7' and edited my prior post. Tested with gcc 4.9, 5.5, 6.4, 7.3, and 8.2. Curious if your build also passes.

Thanks so much for the quick responses and the patch. I will try it this evening after work.

I've tried building dosbox again. Thank you, krcroft, for the links. I had not tried building vanilla dosboxsvn yesterday. The vanilla builds successfully with and without your patch. The errors I get are when attempting to build the ECE r4173 - something wrong with my version of fstream that is being called by mp3.cpp. It did not happen in 4168 or earlier.

Dracolich wrote:

I've tried building dosbox again. Thank you, krcroft, for the links. I had not tried building vanilla dosboxsvn yesterday. The vanilla builds successfully with and without your patch. The errors I get are when attempting to build the ECE r4173 - something wrong with my version of fstream that is being called by mp3.cpp. It did not happen in 4168 or earlier.

Perfect; this is expected because the rev7 patch you tested hasn't been applied to ECE r4173 yet, but your good news bodes well. Yesterplay80 - I think we're all set to move to rev7 of the codec patch. Best regards.

New binaries and source archives based on r4175 and your patch rev. 7 are online!

Hello everyone, I found a small bug compiling ECE r4175. I'm using debian testing.

If I extract DOSBox ECE r4175 (Linux source).7z and compile it from a directory with spaces (ie '/home/user/dosbox ece r4173/'), the compilation ends with the following error:

/bin/mkdir -p '/home/user/dosbox ece r4173/src/libs/decoders/internal/lib'
/bin/bash ../libtool --mode=install /usr/bin/install -c libogg.la '/home/user/dosbox ece r4173/src/libs/decoders/internal/lib'
libtool: install: /usr/bin/install -c .libs/libogg.lai /home/user/dosbox ece r4173/src/libs/decoders/internal/lib/libogg.la
/usr/bin/install: target 'r4173/src/libs/decoders/internal/lib/libogg.la' is not a directory
make[8]: *** [Makefile:410: install-libLTLIBRARIES] Error 1

If I extract ECE and compile it from a directory without spaces, the compilation ends well.

It seems that some var is missing its '' so that it expands to '/home/user/dosbox ece r4173/src/libs/decoders/internal/lib/libogg.la' instead of 'r4173/src/libs/decoders/internal/lib/libogg.la'

r4165 (at least) and previous versions are not affected

Regards

Thanks, guys, ECE r4175 builds and works great now! 😎

pantercat, thanks for the bug report regarding compiling inside a directory with one or more spaces.

This is a known auto-tools issue reported during the ./configure phase of the Opus dependencies. They warn that libtool does not properly handle current-working-directories with spaces, and indeed the failure occurs when they make install to a properly quoted "$(CURDIR)" prefix.

To fix this, I now avoid using --prefix="$(CURDIR)" and make install all together, and instead simply copy out the handful of library and header dependencies after make succeeds.

I've confirmed the build runs clean inside directories with spaces. If you want to try it, patch the latest DOSBox r4175 source with the rev8 patch attached here: AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks
(Direct link to the patch: download/file.php?id=55737)

Actually "./autogen.sh && ./configure && make" was enough to get the error.

Thanks for the updated patch. I patched dosbox r4175 with rev8 patch and "make" ends successfully inside dirs with spaces.

Thanks for the confirmation!

I've just compiled DOSBox ECE r4176 on my Raspberry Pi 3 B+ running Raspbian and it runs flawlessly. Compiled out of the box without any changes. I had previously installed munt 2.3.0 before so had mt32emu library with headers. Thank you so much for the linux build.
This might be integrated into RetroPie one day.

P.S. for Dosbox keyboard to work correctly when starting directly from console (without X desktop) had to set use-scancodes=false configuration option, otherwise keyboard is messed up (it's a well known dosbox workaround)

troydm wrote:

I've just compiled DOSBox ECE r4176 on my Raspberry Pi 3 B+ running Raspbian and it runs flawlessly. Compiled out of the box without any changes. I had previously installed munt 2.3.0 before so had mt32emu library with headers. Thank you so much for the linux build.

You're welcome! Great to know it runs on the Pi as well, thanks!

Forgot to mention, it would be nice to add output gain and reverb output gain settings as I had to manually set them in midi_mt32.cpp using setOutputGain and setReverbOutputGain methods on Synth object and recompile dosbox ece. Also for future contribution/development it would be nice to have github repository so we could make fix/improvement contributions via PR requests and better track source code changes

Is it possible to change the fluidsynth volume?