Reply 60 of 145, by bam
wrote:if these flatpak builds will be distributed generally beyond Bam's use and supported by the DOSBox team
Well, actually, Qbix doesn't care about Flatpak.. 😉
wrote:if these flatpak builds will be distributed generally beyond Bam's use and supported by the DOSBox team
Well, actually, Qbix doesn't care about Flatpak.. 😉
You misunderstand, Dosbox not built against release versions or SVN, with patches added are not supported here at all.
FYI: I just compiled a new version of DOSBox ECE (r4180.3) with the latest patch from krcroft integrated.
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
Thanks for the heads up! Glad the patch is still applying cleanly.
I've done some minor code clean-up but nothing worth posting yet (improved comments, defined all unchanging variables as const for better readability, added versioning inside the mp3 fast seektable data file, fixed all warnings when building with -Wall and -pedantitic when compiled with gcc versions 4.x through 9.x.)
Regarding the "single header Opus decode" side, David continues to make progress. Nothing functional for me to integrate yet though. You can read his progress commentary here:
https://github.com/mackron/dr_libs/blob/opus/ … dr_opus_log.txt
As for Xiph's Opus decoder used in this patch, there was one recent code change:
https://github.com/xiph/opus/commit/9791b22b2 … 0cad58557c78007
Because this patch's makefile pulls the xiph master sources, this update will be in your build.
krcroft, do you know of any code in your patch that could cause DOSBox to crash when switching between CD images if more than one is laoded? I had two reports until now of DOSBox ECE users that have this problem since I added your patch. One uses Linux, the other Windows, so at least it's OS independent. Unfortunately I can't reproduce the crashes, and for many others it seems to work just fine, too, so I have no idea where to start searching.
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
Hey Yesterplay,
Thanks for the heads up. I didn't touch that part of the code, but will certainly kick the tires and try to reproduce it or at a minimum create a debug build of just SVN plus the audio support patch that you can pass onto those reporting it.
Another thing I can do is pull in the handful of minor fixes that have been made in the stand-alone codecs; although I don't recall any of them involving memory / crashing / deallocation type issues. Worth a shot in any case.
Will PM to cover any other details.
Hi.
I could also suggest try to build DOSBox Flatpak https://github.com/flathub/com.dosbox.DOSBox with the patch applied, to see if it crash also.
That way we could eliminate differences in memory allocation on different systems, for ease of debugging.
Also, think virtual machine environment could help here as well.
Feel free to ask help in Flatpak building.
Sounds good Bam.
Yes, any tips or a script you can send to let me generate and run a flatpak build would be very helpful. I'm on Ubuntu 18.04, kernel 5.0.10 (latest stable as of this message).
Thanks!
Yesterplay: probably good idea to get either the cd images or at least the cue files (if applicable) to be able to pinpoint the problem more precisely. I always find it more helpful to get as much information as possible as the problem may lie entirely elsewhere
wrote:Sounds good Bam.
Yes, any tips or a script you can send to let me generate and run a flatpak build would be very helpful. I'm on Ubuntu 18.04, kernel 5.0.10 (latest stable as of this message).
Thanks!
Krcroft, fine!
Unfortunately, I can't seems PM yet. Can we converse by the other means: email, etc.? My Telegram is @bam80
Krcroft, here is the commands to build and test run DOSBox flatpak:
git clone git@github.com:flathub/com.dosbox.DOSBox.git
cd com.dosbox.DOSBox/
git submodule init
git submodule update
flatpak-builder build-dir com.dosbox.DOSBox.json
flatpak-builder --run build-dir com.dosbox.DOSBox.json dosbox
To apply patches, see com.dosbox.DOSBox.json in the cloned repo.
If you have any questions, feel free to ask!
Thank you Bam!
Revision 9 Updates
This is a maintenance release without function changes.
Under the hood things to continue to improve both in what I'm working on the DOSBox side (comments, warnings, etc) and especially within the one-header-file packages this patch uses and includes. See the changelogs below.
Pro-tip for FLAC users: after ripping your cd-audio to FLAC, add rapid seek-points to your files with metaflac --add-seekpoint=1s track.flac
You will gain instantaneous track seek times when playing games that use one-big music file and jump around within it - like Jones in the Fast lane by Sierra and Stellar 7 by Dynamix.
The screenshots below summarize the improvements made between the last patch release and this release. All changes are integrated into this new patch.
Downloads:See the first post for the new patch which applies to DOSBox r4222 (use -p1) along with Linux and Windows 64-bit static-binaries. If someone wants a new OSX binary, let me know!
DOSBox audio updates
Opus audio-codec updates
Dr FLAC and Dr MP3 codec updates
STB Vorbis codec updates
(note: only a subset of the listed changes pertain to the vorbis header we use; the others are part of the same repo so appear in the log)
xxHash algorithm updates
wrote:krcroft, do you know of any code in your patch that could cause DOSBox to crash when switching between CD images if more than one is laoded? I had two reports until now of DOSBox ECE users that have this problem since I added your patch. One uses Linux, the other Windows, so at least it's OS independent. Unfortunately I can't reproduce the crashes, and for many others it seems to work just fine, too, so I have no idea where to start searching.
Turns out there's a bug in SVN affecting mounting multiple iso images, it can trash random memory so may be the cause of these issues.
It's the same bug as described here: https://sourceforge.net/p/dosbox/bugs/368/
jmarsh - thanks for squashing this concern regarding the patch.
I've been valgrinding my prior patch and now this patch with all codecs supported, and am unable to generate any memory issues in my portion.
(I also can't reproduce the original issue, so will dig into your link!); thanks again.
wrote:Turns out there's a bug in SVN affecting mounting multiple iso images, it can trash random memory so may be the cause of these issues.
It's the same bug as described here: https://sourceforge.net/p/dosbox/bugs/368/
I wasn't able to get DOSBox to outright crash (segfault or bus-error under Linux), but I do see uninitialized memory/object accesses when dealing with cdroms (see attached valgrind-r4222.log)
I've attached a patch (to r4222) that addresses these and produces the attached clean report (valgrind-r4222-iso_and_cdrom_member_initializers.log).
Apply the patch inside the root of the r4222 source tree with: zcat dosbox_r4222-iso_and_cdrom_member_initializers.patch.gz | patch -p1
This also seems to fix the hang/lockup when quitting that I sometimes get after mounting a cdrom (although not extensively tested).
Qbix already had a patch in his tree when I stumbled onto the problem (subUnit being used uninitialized).
But looking at the code again, I have to wonder why isoDrive::UpdateMscdex() takes subUnit as a reference parameter when it's already a member variable...
Yeah setting them to 0 is enough to avoid the crash, but I think this should be done as well, as always connecting the multiple iso's to the first drive is probably not correct.
Water flows down the stream
How to ask questions the smart way!
wrote:Yeah setting them to 0 is enough to avoid the crash, but I think this should be done as well, as always connecting the multiple iso's to the first drive is probably not correct.
Yes, I think we should stop the music before deleting, because SDL could still be accessing some of prior allocated buffer/pcm memory.
wrote:Yeah setting them to 0 is enough to avoid the crash, but I think this should be done as well, as always connecting the multiple iso's to the first drive is probably not correct.
I tested your patch as-is loading many, single-file BIN-CUE pair containing embedded CDDA tracks.
So I had imgmounts to D: and E:, both with many swappable discs behind them.
I then played them in Open Cubic Player 2.6.0pre6 (launched with dos32/a) and did lots of on-the-fly disc swaps (ctrl + F4s) while the audio tracks were playing.
CubicPlayer recognized the drive "eject and reload" MSCDEX calls and properly restarted playing the current track once the "new disc" is ready. It also handled switching from drive D: to E: without issue.
This was all being monitored by valgrind and there were no issues reported during or after closing down the player. Not sure how else to beat it up, but it's looking a lot better than the droves of unassigned accesses prior to this.
(combined our work and am using the attached in my latest branch; both run clean in the above scenario)