SDL_Sound nightmare.

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-24 @ 22:20

Well, I've finally reached a milestone :) For me that is. I've gotten all the extra libraries to build without issue, even SMPEG, which it turns out actually needs SDL2 not SDL1, as all the instructions say. So I had to grab SDL2, change all the input libraries to SDL2 versions, and point it to the SDL2 library & include directories. Means having to have SDL2 with my DOSBox package for SMPEG to use, if it worked (another story.) But the drivers all compile, the test programs all play the music in question just fine. Now on to putting them to use with SDL_Sound.

Well, first, smpeg.c has an error on line 173, not enough arguments provided. So, since MP3 is also handled internally, I just disabled it. I tried other options later, but that is covered further down. After that, and going back to build libmodplug as a shared instead of static library, it built just fine.

Next issue, SVN-3998 has 2 small issues in cdrom_image.cpp. The first at line 118 uses the lround macros or function that windows doesn't have (I searched.) A quick define of my own to accomplish the same thing solved that. The other problem at line 122 is that the data call "numeric_limits<int>::max()" which returns the maximum value a normal int can hold, seems to conflict with the 2 instances of "#define max(a,b)" which returns the higher of the 2 values (a or b.) Another easy fix, just replace the numeric_limits with "INT_MAX", breaks portability, but this is for personal use only.

Now, DOSBox (after adding the libraries into Input like I was supposed to do but forgot,) builds just fine. Yay :) Mounted a OGG format cue/bin, and it worked like a charm. I, personally prefer MP3's, so I mounted a MP3 format cue/bin and now I get no audio :( Went through all the formats SDL_Sound supports with the following results:

    FLAC - Playback issues covered in another thread
    MP3 - No audio
    WAV - No audio
    RAW - Untested, how is it any different than just a normal cue/bin with audio tracks in the bin file?
    AU - No audio
    MIDI - DOSBox reports corrupt or bad cue/bin image (won't mount)
    VOC - 16-bit will mount (takes it about 5 seconds to actually mount,) and works fine. 8-bit crashes DOSBox
    OGG - Works fine
    MOD - Including all the different formats, same as MIDI "corrupt" cue/bine and no mount.
    SHN - Couldn't test, as I can't find a way to convert "to" that format.
    SPEEX - Whatever the extension is for this. SDL_Sound says they support it, but can't find the code for it. I have the library for when/if it ever appears.

Not really all that interested in anything other than the MP3 format. None of my portable players (I have 3,) support OGG, so most of my stuff is in MP3 format. At this point, I decided to take a chance with SMPEG, and tried to "fix" the code in SDL_Sound that kept me from using it. Basically, that one command that doesn't have enough arguments. Digging through the SMPEG source code, I tracked down that it seems to be a size report on the first argument. Could be wrong about that, probably am, as I'll explain in a bit. So, I added in an argument reporting the size of the first one. Now it compiled, DOSBox excepted it fine. Only, when I mount an MP3 format cue/bin, DOSBox crashes :(

DOSBox code is clearly set so that as long as SDL_Sound covers it, DOSBox will just pass the file data along and take what it gets back (SDL_Sound does the actual decoding work.) Because of this, I went ahead and used the dynamic version of SDL_Sound (which also forced using dynamic versions of some of the codecs as well.) So, the problem almost definitely lies with SDL_Sound and not DOSBox (other than the 2 minor issues mentioned above.) I'm just hoping (since getting help from SDL_Sound seems to be rather difficult,) that a coder here has some hints for me :) This doesn't speak to DOSBox not even appearing to try the MIDI or the MOD styles. Though that could be SDL_Sound as well saying "I can't handle that."

On a related note. If I eliminate everything except OGG format from SDL_Sound, I can get a static build that DOSBox will accept and use without adding to the DLL's that need to be available. OGG format cue/bin files still worked in this case.

On an unrelated note. To fix Aero issues, I have an altered SDL.DLL file, and every mode except ddraw, surface, & overlay can switch back and forth between fullscreen & window without disabling Aero. I remember having the altered source as well, though I can't say if I altered it myself, or used someone else's patch to do so. In the loss of my data files (several moves & a failed HDD,) I've lost that. I've been getting by using exported lib/exp/def files from the DLL, with include files and the SDLmain.lib from a normal build. Does anyone remember the changes, have the patch (.diff) files, or the full source for this? I've dug through my past posts here, and can't seem to find/remember anything :(
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby Dominus » 2016-9-25 @ 05:23

Did you look at the Dosbox wiki? There is something that needs to be different in the cue file index for mp3 to work. I vaguely remember a thread on Vogons several years back about this.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7932
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-25 @ 05:59

I couldn't find anything on the Wiki or in Vogons that applied specifically to MP3, everything reads like it applies to all compressed formats. The main one being the need to include "PREGAP 00:02:00" just before the INDEX line of Track 02. Which I have done in the case of all formats I tried. I couldn't find anything specific to just MP3 or even specific to everything except OGG. I'll keep looking, of course, but I'm pretty much running out of places to look ;(
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-25 @ 08:09

Well, I have to go back to the drawing board to get MP3's working. I didn't do a full test run with the playsound test program SDL_Sound produces. For the most part, the problem falls into a communication issue between DOSBox and SDL_Sound, as playsound ran through everything I could generate/find myself and played it without issue. With 2 exceptions. I couldn't get it to play midi or mp3 files at all. The internal MP3 library reports "Free Format Not Supported." While SMPEG just reports "Format Unsupported." MIDI files get the same result. So, That leaves just figuring out why everything else refuses to work in DOSBox (except for OGG & 16-Bit VOC,) but works fine with Playsound.

MP3 is what I'm really after, though being able to replace some of the CD Based music in a couple of games with MOD or even select MIDI files is intriguing :) So I guess, since the project seems to have died (over 8 years since any activity,) I'll have to dig through the MP3 code myself to see if I can get it working. Would be much easier if I was a better programmer :(
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby NY00123 » 2016-9-25 @ 18:25

While probably not relevant, just some gotcha that it may be good to be aware of:

In contrary to official SDL satellite libraries like SDL_mixer + SDL2_mixer, there are no separate SDL_sound and SDL2_sound projects; Just SDL_sound.

You can, however, build SDL_sound to depend on either SDL 1.2 or SDL 2.0. This way, the built SDL_sound library can be used either with SDL 1.2 apps, or SDL 2.0 apps - but not both.

Problem is, if you build SDL_sound against SDL 1.2, it's still possible to use it with an SDL 2.0 app, as long as SDL_sound isn't actually used (e.g., MP3 playback). Once an attempt to actually use it is made, you can get unexpected behaviors (say a crash)!

The opposite holds as well (e.g., building SDL_sound against SDL 2.0 and then using it with an SDL 1.2 app).
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

Re: SDL_Sound nightmare.

Postby Dominus » 2016-9-25 @ 19:26

I think this is fixed in SDL_sound mercurial. SDL_sound built against SDL2 should now have SDL2_sound libs.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7932
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-25 @ 20:06

I did find an SDL_sound that actually works almost completely (through it's own playsound.) The only thing not working is MIDI playback, and possibly the shn format, as I don't have access to audio files in that format. The problem is, it's old, as in too old for DOSBox to use. Well, not completely, I could disable the seek function in DOSBox, and it would work, as that's the only thing this one doesn't have. I have actually been editing the older version to add seek functionality into it, been learning quite a bit about it. Because of its modularity, its actually a fairly simple system. Quite elegant actually, and it doesn't seem that complex to expand. As long as you understand how each module needs to operate in communicating between SDL_sound and any functions that actually handle the data stream, a module for just about any audio format can be built. Either by incorporating the appropriate routines into the module itself, or just using the module to communicate with the appropriate library.

All that being said, I haven't given up hope. I may just end up starting my own version of SDL_Sound in a new VS10 project. I'd let VS10 set up the base project, then start importing from the original SDL_Sound source, making alterations a step at a time. A lot of work, but saves quite a bit of time. It also will lessen the impact of the visualc.zip seeming to be quite a bit out of date has. The project included with the latest SDL_Sound, contains many files & settings that are apparently no longer used, referenced, or even present in some cases.

That's a long running project though. One thing the new (old) SDL_Sound had was included, compiled, Visual C libraries & DLL files. They were also old, but it included an SMPEG that worked great. Been looking at that too, as well as examining the SMPEG I have (412,) to see about getting it to compile with SDL1 instead of SDL2. Never was a big fan of mixing those in the first place.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby Dominus » 2016-9-25 @ 20:15

Ping me tomorrow and I can have a look at how my favourite OS X packager (macports) handles smpeg.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7932
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-26 @ 08:09

I thought I actually had it solved :( After quite a long bit of time, I added in the seek function for everything. Many of them had fairly simple hacks... That is, they just calculated the current position with the desired position, then reset to the beginning and "skipped" ahead to the new location. But it wasn't that big of a bother to transpose the code from the newer version to the one that worked without major rewrites. Playsound plays everything just fine, except for MIDI files still. DOSBox now accepts it, as it has the seek function. Only the same problem persists :( Only now the console actually gives me a bit of data when an MP3 file is mounted. Many, many lines of audio skipping samples, then the image mounts. Enter the game, and no CD music :( Re-built SDL_Sound with skipping disabled for MP3's and it mounts fast (without all the audio messages,) but still no music.

I'm starting to get a little frustrated :( I'm going to beat this some day. For now, I think I'm going to pull SDL_Sound back out until I can get better information, or another option comes up. The main SDL_Sound page hasn't been updated in over 8 years, so maybe it's time to look into another option for this. The GIThub source shows a better scale. Very little activity since late 2002. Brief spikes early on, but then long passages of nothing with occasional bits of activity. May not actually be a dead project, but it's hanging by an extremely slender thread.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby Dominus » 2016-9-26 @ 08:39

Ok, looked some things up. MacPorts differs between SMPEG and SMPEG2. SMPEG is still version 0.4.4 and is built against SDL 1.2x, but uses these patches for building http://ooo.mirror.garr.it/mirrors/macpo ... peg/files/
The mpeg patches might be relevant.

AFAICT SMPEG is developed mostly by one of the SDL developers (Ryan C. Gordon). As is SDL_Sound.

And you should probably judge the SDL_sound activity by their mercurial code repository http://hg.icculus.org/icculus/SDL_sound/ (still 4 years dead)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7932
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: SDL_Sound nightmare.

Postby NY00123 » 2016-9-26 @ 19:33

I suppose the mention of MIDI is just for testing, since I don't see why you'll want to use these in a cuesheet at all (except for maybe playing alternative tracks).

Dominus wrote:I think this is fixed in SDL_sound mercurial. SDL_sound built against SDL2 should now have SDL2_sound libs.


Really? I'm quite sure I'd gotten just a library named "SDL_sound" from the 4 years old SDL_sound sources, even if built against SDL2.

I should re-check if I really want to be sure, though.
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

Re: SDL_Sound nightmare.

Postby Dominus » 2016-9-26 @ 20:05

Nah, seems I'm wrong. Mustvhave been snother SDL satellite
User avatar
Dominus
DOSBox Moderator
 
Posts: 7932
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-26 @ 23:40

NY00123 wrote:I suppose the mention of MIDI is just for testing, since I don't see why you'll want to use these in a cuesheet at all (except for maybe playing alternative tracks).


Both alternative track & I like having libraries with full functionality (most of the time.) As for track replacement, an OGG or MP3 file (the main ones I really want enabled,) is around 4-10 MB (depending on duration & compression levels,) while a MIDI, with the same music, would be around 10-100 KB instead. Though, to really do MIDI right, would need to be able to include a soundfont (or some other type of sampled instrument set.) That's one thing the Amiga's MOD files had over MIDI.

An alternate method, though one only usable on systems with plenty of RAM, would be to just create a RAM buffer of the decompressed/converted audio data for each track. But that's up to ~700 MB of RAM that would need to be reserved & set aside. Considering most modern system function with several GB of RAM, that's doable, but IMHO wasteful. Would also lead to a delay during the mounting process. But it would make actual playback a lot simpler & smoother.

At this time, though, MIDI & MOD playing is moot. DOSBox doesn't allow it, even though SDL_Sound says it's fine (for the MOD files.)
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-27 @ 00:44

Dominus wrote:Ok, looked some things up. MacPorts differs between SMPEG and SMPEG2. SMPEG is still version 0.4.4 and is built against SDL 1.2x, but uses these patches for building http://ooo.mirror.garr.it/mirrors/macpo ... peg/files/
The mpeg patches might be relevant.

AFAICT SMPEG is developed mostly by one of the SDL developers (Ryan C. Gordon). As is SDL_Sound.

And you should probably judge the SDL_sound activity by their mercurial code repository http://hg.icculus.org/icculus/SDL_sound/ (still 4 years dead)


My download actually included all (it seems,) of the past revisions. I set up the 0.4.4, applied the patches, did a bit of maintenance (pointing to where library & include files were etc...) added in the files that the visual_c project left out, added in the include libraries that the project left out, and it compiled fine with SDL1 :) It also seems to work fine too (with the SDL_sound playsound program.) Though, I did have to use the visualc.zip file provided by the 412 (0.4.12??) release. The zip files for every single one of the alternate releases were corrupt. I then, just to check, tried out the 0.4.5 release, and it worked just as well. So SMPEG is nicely set up. Not sure I like the requirement for SDL2 that seems to be part of the formal progression now. Also, this still doesn't address getting MP3 files working in DOSBox.... Ok, it might. Have to rebuild SDL_Sound now. I lost all my edits when I updated to the mercurial version you pointed me too. Haven't actually worked on that one any yet.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-28 @ 15:07

There's going to be a delay on further work. Somehow the base includes (stdlib.h etc...) were un-write-protected and altered during one of my editing sessions. Visual Studio isn't as forgiving as many other environments, so I usually have to tweak things here and there to get past certain errors. I usually do this by tracing through the files, starting with the main control file, and correcting things as I come across them (I love you red error/warning markers.) During this, I must have pulled up one or more of the standard include files without noticing, and "corrected" something in there. Anyways, this lead to 100's of syntax errors (that prevent compiling,) popping up any time I tried to compile "anything," even a quickly written "hello world" console project. I attempted to just do a repair (had to hunt & dig for my DVD.) But that didn't help :(

So, right now, I'm in the middle of removing Visual Studio, getting set up to re-install it fresh & clean. That should allow me to get to work again. I'm going to create a quick archive of all the include directories as well this time, just in case I do something boneheaded like this again.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby Dominus » 2016-9-28 @ 15:23

Use a versioning system. Even if you use it only local you could have avoided some pain already.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7932
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-9-29 @ 23:19

If it's just the going through the code correcting the little things that Visual C throws a fit over, that's not a problem. If your talking about the accidental damage, that was with the "supposedly" protected system files :( How they became un-write-protected is still beyond me. I got VS2010 reinstalled, built a couple of my known good projects to make sure, and started working on things again, when I made a rude discovery :( The uninstall engine for Visual Studio is crap (or at least the 2010 and prior versions were.) Started getting random catastrophic failures of the IDE, and finally traced it to an "improper" uninstall prior to the re-install. Had to download Microshaf...um... Microsoft's special un-install program to rip all things VS out, so I could do a proper (and hopefully soon to be working right again,) install :(

Anyways, in the middle of that now.... But, before things went kablooie again, I had a working SDL_Sound up, but an older version. I was checking out the first build that included Visual C files. Even that one had major issues (files in the project list that didn't exist, or were not in the right place, etc...) After fighting with that one for a while, I had just started to build my own VS solution & project files from scratch when I discovered this wonderful feature (I'll never forget that quote,) of Visual Studio.

So, please bear with me as I hope the dust will clear out soon, and I can get back to work :)
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-10-01 @ 14:41

Ok, everything back on track now. Using playsound I've gotten MIDI working :) It turns out that you have to have timidity.cfg available in either the current directory (where SDL_Sound is being activated, so that would usually be where Dosbox.exe is - or playsound in this case,) or in the "\timidity" directory (which is the timidity folder in the root directory of the current drive.) Also, the config file has to be error free, or SDL_sound disables MIDI support. I had to actually step through the timidity source code to discover this. I couldn't find any mention of it in the readme files. Also, even if it finds an error free config file, it won't actually make any sound unless you also load an instrument set. SDL_Sound currently only supports using GUS patch files, the current Timidity drivers also support SoundFont files, and WAV files for the intsruments. This actually tempts me to get/build timidity libraries, and use it separately instead of the stripped down code that SDL_sound uses internally.

Anyways, even though MIDI is working through SDL_Sound, DOSBox still won't mount it :( Oh well, I'm not exactly desperate to have midi track replacement as an option. The problem is, no matter how I tweak the MP3 routines (within my limited programming ability,) I can't get MP3 tracks to play in DOSBox :( Play just fine with Playsound (the small console player that SDLSound includes,) plays both just fine. I consider SDL_Sound working now, though. I'll continue what I'm doing, and get all of it's options up & running (still debating using a separate timidity library as well, but have time for that.) Hopefully someone can figure out why DOSBox is having a problem with pretty much everything except OGG, and I can get that fixed eventually.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-10-02 @ 17:03

Ok, latest available source, carefully built VS2010 solution from scratch (no more converting the VisualC files that haven't changed since 0.1.4,) and I've gotten everything working just dandy through playsound. Still have extremely limited use in DOSBox. Pretty much OGG only. I've been searching to see if I can find if there is something extra I have to put in the cue file for MP3 files, without much luck. But the main key is that I have SDL_Sound pretty much worked out for now. I've gone through the code over and over (not always by choice,) and I cannot figure out why DOSBox+SDL_Sound just doesn't like MP3 files.

I'll keep digging at it, but I've pretty much reached the end of my ability :( Looks like I'm stuck with OGG. I'll keep poking at it, I might get lucky & figure something out.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: SDL_Sound nightmare.

Postby FeedingDragon » 2016-10-09 @ 14:09

Well, now I'm just frustrated again. Had to re-install my system. Digging around, made the startling discovery that it works just fine with the DAUM build, and was wondering if it was my SDL_Sound build or my DOSBox build that was the issue. So, when I tried to compile the DAUM build with my SDL_Sound library, and discovered that VS 2010 can't do it, I went ahead and decided to upgrade my VS yet again. Reading up on the offending code that 2010 can't handle, 2012 was the oldest one that could handle it. I tend to stay with the older VS versions because Microsoft likes to kill support for older systems (and I like to build for my 95, DOS, 3.1, etc... machines as well.) But, with my tech account, it was actually considerably cheaper to upgrade to 2013, only I ended up messing things up with the switchover :( So, I'm finally getting back up and running, and will start trying again to figure out where I'm going wrong shortly.

On an unrelated, and totally off topic, note: Does anyone know why Vogons would suddenly stop sending me e-mail notifications on threads I'm subscribed too? Over the last week of install work, it took me a while to realize that I haven't received any notifications. Only, I come here to check, and several of the threads I am watching have quite a few replies.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Next

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests