VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 500 of 932, by krcroft

User metadata
Rank Member
Rank
Member
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!

Reply 501 of 932, by Yesterplay80

User metadata
Rank Member
Rank
Member
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:
https://www.vogons.org/viewtopic.php?f= ... 39#p695839

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

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 502 of 932, by krcroft

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:

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

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

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

Reply 503 of 932, by Dracolich

User metadata
Rank Newbie
Rank
Newbie

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.

g++ -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
mp3.cpp: In function ‘void load_seek_table(Sound_Sample*, std::vector<unsigned int>&)’:
mp3.cpp:229:46: error: no matching function for call to ‘std::basic_ifstream<char>::basic_ifstream(std::string&, const openmode&)’
ifstream infile(filename, ios::binary);
^
In file included from mp3.cpp:30:0:
/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]
basic_ifstream(const char* __s, ios_base::openmode __mode = ios_base::in
^
/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*’
/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>]
basic_ifstream() : __istream_type(), _M_filebuf()
^
/usr/include/c++/5.5.0/fstream:481:7: note: candidate expects 0 arguments, 2 provided
/usr/include/c++/5.5.0/fstream:455:11: note: candidate: std::basic_ifstream<char>::basic_ifstream(const std::basic_ifstream<char>&)
class basic_ifstream : public basic_istream<_CharT, _Traits>
^
/usr/include/c++/5.5.0/fstream:455:11: note: candidate expects 1 argument, 2 provided
mp3.cpp:284:60: error: no matching function for call to ‘std::basic_ofstream<char>::basic_ofstream(std::string&, std::_Ios_Openmode)’
ofstream outfile(filename, ios::trunc | ios::binary);
^
In file included from mp3.cpp:30:0:
/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]
basic_ofstream(const char* __s,
^
/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*’
/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>]
basic_ofstream(): __ostream_type(), _M_filebuf()
^
/usr/include/c++/5.5.0/fstream:682:7: note: candidate expects 0 arguments, 2 provided
/usr/include/c++/5.5.0/fstream:656:11: note: candidate: std::basic_ofstream<char>::basic_ofstream(const std::basic_ofstream<char>&)
class basic_ofstream : public basic_ostream<_CharT,_Traits>
^
/usr/include/c++/5.5.0/fstream:656:11: note: candidate expects 1 argument, 2 provided
Makefile:504: recipe for target 'libdecoders_a-mp3.o' failed
make[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

Reply 504 of 932, by krcroft

User metadata
Rank Member
Rank
Member
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: source.dosbox.com/dosboxsvn.tgz
2. Download the updated patch: https://www.vogons.org/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)

Last edited by krcroft on 2018-11-19, 17:29. Edited 3 times in total.

Reply 505 of 932, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 506 of 932, by krcroft

User metadata
Rank Member
Rank
Member
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.

Reply 508 of 932, by Dracolich

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 509 of 932, by krcroft

User metadata
Rank Member
Rank
Member
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.

Reply 510 of 932, by Yesterplay80

User metadata
Rank Member
Rank
Member

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 511 of 932, by pantercat

User metadata
Rank Newbie
Rank
Newbie

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

Reply 513 of 932, by krcroft

User metadata
Rank Member
Rank
Member

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: https://www.vogons.org/viewtopic.php?f=41&t=62203
(Direct link to the patch: https://www.vogons.org/download/file.php?id=55737)

Reply 514 of 932, by pantercat

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 516 of 932, by troydm

User metadata
Rank Newbie
Rank
Newbie

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)

Reply 517 of 932, by Yesterplay80

User metadata
Rank Member
Rank
Member
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!

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 518 of 932, by troydm

User metadata
Rank Newbie
Rank
Newbie

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