Did you check your spam filter/folder or is the account you receive these mails not forwarding to your main mail account or something like thst? Other than that only unsubscribing (in the notification email) should prevent you receiving these emails.

Hmmm. They've never been SPAM filtered before. I tend to just trash the spam files, and I may have accidentally clicked "spam" instead of "delete" on one. Going to have to wait for the next notice to be sent now. I use yahoo for my mail now, after 6 different e-mail addresses in a 3 year period, I stopped going with my ISP for e-mail, and just started using a yahoo account. I had been receiving them just fine till recently. So, no more deleting my spam folder blind until I know for sure that that isn't the issue.

FeedingDragon wrote:

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.

This happened to me one week months ago, send PM to a mod or better to an admin.

lightmaster wrote:

FeedingDragon wrote:

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.

This happened to me one week months ago, send PM to a mod or better to an admin.

Thanks, but it actually turns out that I accidentally clicked the "spam" button instead of the "delete" button on a message. I just discovered a notification (this one,) in my spam folder, and marked it as "not spam" now. Hopefully I won't do that again 🙁

YW
Cool you did realize, how's SDL_Sound? Still a nightmare??
Cheers

Still in the process of getting my system back up and running. Waiting on some 50 GB disks. After fighting with my Windows 7 install multiple times, I'm building a restore point past all that crap. Waiting till that's done before I start installing anything I might want to upgrade later. Right now, my C drive is 62 GB, which will take 2 50 GB disks (have 5 on the way.) I've been trying to cherry pick what to install until they get here on Thursday. After that, its back to re-building my SDL_Sound.lib & dll (I accidently didn't include the ones I already built with my backup.) Then try Daum's source code to see if it's my DOSBox build or my SDL_Sound build that I'm having an issue with. My SDL_Sound worked great playing everything from the Playsound testing executable. But in DOSBox, only OGG format worked. In Daum's build, everything worked (except MIDI & MOD files.) Once I know where to look, I can start searching for exactly what I need to do 😀

In all honesty, it's not a major issue, I only have 3 games (maybe,) that even use Audio CD tracks. It's just a challenge I took quite a while ago, that I want to see through to the end. I thought I had it licked. I had finally tracked down all the drivers that SDL_Sound wanted, and gotten them to build right. Then I had gotten SDL_Sound to build right. Only, I had this issue, that I just couldn't find a fix for 🙁

There is really only one more issue I'm having with my updated build.... I can't remember what I did (or someone else did, don't even remember that much,) to get SDL to not kill Aero every time I switch to full screen (it causes graphics anomalies.) The SDL.DLL file I have now is the result, and I was able to export a lib & exp files from it. But I would feel more comfortable if I knew what was done with the source code to get it in the first place. I have confirmed it is the SDL that fixes the issue... Using a standard DOSBox patched SDL from v 1.2.8 through 1.2.15 and Aero is disabled in full screen. Use the already compiled SDL I have, and it doesn't get disabled. I'm starting to get a little frustrated with my memory issues 🙁

Isn't it just a backend order issue in the SDL sources? Directx after windib or something like that. I think there was a patch in the Dosbox sources at some point. Or similar...

Edit: This? DOSBox & Aero (Transparency disabled on Full/Windows mode switch)
Use the search... 😉

I did use the search, and the fixes I found were not what I was looking for. They were, at best, work arounds that don't solve my underlying problem. When Aero is turned off, I start suffering graphic anomolies, and my graphics driver eventually resets (and yes, I have updated my driver, I've downgraded my driver as well.) The SDL.DLL file I've been using leaves Aero turned on in full screen, so that doesn't happen. I believe, only ddraw still shuts Aero off, and I remember looking into that, but dropping it (about all I remember from that period.)

What I find frustrating is Aero is turned off, by default, when you install Windows 7. Aero is supposed to be an optional appearance setting. Yet, back then, when I still had tech support coverage with Windows 7, Microsoft informed me, in no uncertain terms, that turning Aero off was not supported, and that they would not troublshoot or try to solve any problem that only appeared when Aero was turned off. Their answer was to say, "Don't turn Aero off, good day." That, and their forcing me to upgrade to Windows 7, in the first place, is why I started thinking of them as Microshaft instead of Microsoft 🙁

IIRC, Turning Aero off will potentially make the desktop slower due to everything being run on the CPU instead of the GPU. In newer versions of Windows it cannot be disabled at all.

If Aero is actually making your computer slow then it's either a bad driver or an ancient video card.

No I am not an Aero fan.

I don't mind Aero, and my vid card isn't that old. I'm currently running a Radeon HD 6670 with Catalyst 8.982-120727a-145315C-ATI (whatever that translates to, it's the most current version.) Also, what I get are.... Well I call them tear drops. Everything looks fine for a while, but over time more and more spots start looking blurred, as if a few pixels had been smeared a bit. This gets worse, until the monitor shuts down for a second, then the workbench comes back with the "your graphics driver has stopped responding and been reset" message (that's a paraphrase, I don't remember the "exact" wording.) AMD says it's a Windows issue & to deal with Microsoft, Microsoft says I have to have Aero running or they won't even look at it. Since the problem is caused "because" Aero is off, that means they aren't ever going to look at it. So, my only option was to find a way to keep Aero on. Thus.... Microsoft has a new name as far as I'm concerned. According to everything I was able to research at the time, it's something that Windows is doing that is causing the problem. Maybe if I never turn Aero on in the first place it wouldn't occur. But usually, something triggers it at some point or another. I never even knew it existed until something turned it on (don't remember what.)

I have also, so far, been unable to find anyone else that has the problem. Even people with older video cards don't have it. I've changed hard drives, I've changed motherboards, CPU, RAM, DVD Drive, GPU, Sound Card, Floppy drive (I just removed that completely - didn't replace it,) and a complete software overhaul & replace. The only thing that has remained constant is my Windows 7 install, that I bought directly from Microsoft when I finally gave up on XP (They killed 4 versions of XP on me.) So, I'm stuck with Aero, whether I want it or not 🙁 I can't play a game for more than half an hour or so before things get really wonky (if Aero is off.) What am I left with? So, as I said, I worked very hard to find a way to keep it on under as many settings as possible. I only got this far, but it was far enough at the time. I'm just trying to find where I left off, or who I got it from, or whatever. I have a vague memory of looking into color depth (Aero may be getting turned off because of a color depth conflict - that was on one of the sites my search turned up.) That may have been the route I was going down when I got to the current SDL I have. It may have also been another route I came across (or someone else did,) after that had been looked into. I was just hoping someone I had worked with on this had a better memory than I 🙁 Guess they don't, or they haven't read these posts.

FeedingDragon wrote:

I don't mind Aero, and my vid card isn't that old. I'm currently running a Radeon HD 6670 with Catalyst 8.982-120727a-145315C-ATI (whatever that translates to, it's the most current version.) Also, what I get are.... Well I call them tear drops. Everything looks fine for a while, but over time more and more spots start looking blurred, as if a few pixels had been smeared a bit. This gets worse, until the monitor shuts down for a second, then the workbench comes back with the "your graphics driver has stopped responding and been reset" message (that's a paraphrase, I don't remember the "exact" wording.)

If you are able to crash the video driver, that means the video card is likely near the end of it's life. OR (personal experience) your CPU/RAM is faulting under load, OR, your power supply isn't stable.

Failing video cards usually exhibit glitches outside of games if it's failing, I have screenshots somewhere of a R5750 literately showing garbage everywhere something was supposed to be transparent on the desktop. I've seen some brand-new AMD A-series CPU/GPU do the same with just the mouse cursor.

If it's CPU/RAM centric, it will always be replicated under the same conditions. eg, Intel Quicksync on my i-4770 will always hard lock the system under Windows 8/8.1/10 after about 5 seconds. Every time. Such is the case I'm not willing to buy another Intel CPU with an iGPU on it. However it worked JUST FINE in Windows 7. What's the difference? Windows 7 runs it in DX9 mode while Windows 8+ runs it in DX10 mode.

Personally, after going through one round of cursed computer parts, just keep one set of "working spare" parts and swap the parts between the two machines until you find the culprit. The PSU is the least obvious, but can kill parts at random if it's failing.

Um, everything on my system has been replace. When I got my settlement in I did a complete system upgrade. The only thing I didn't buy (then,) was a floppy drive or any new software. I really can't afford to replace my OS at full price, and I'm finally getting used to Windows 7, though I'd still prefer it if I could get a lot of it's issues fixed. Upgrading would only make those worse, from what I've read, anyways.

Also, to note, since setting DOSBox up so that Aero doesn't get disabled, the problem went away completely. I've played games for hours at a time without issue. My system pretty much runs 24/7 (I re-boot occasionally, but rarely just shut it down completely.) No other problems that should crop up (from power issues, bad RAM, etc...) appear. I've pretty much eliminated every possible cause except Aero being turned off. Since nobody else seems to have this issue, I'm pretty much eliminated every possible cause except my OS. There is the possibility that something else I'm installing is responsible, but I "think" I've eliminated everything else.

I've just now started digging around to try and re-download my OS. Though, if my download was corrupted, I find it hard to believe that the corruption was so specific and limited. It is possible, though. Only, Microsoft doesn't seem to have a record of my purchase any more, and with their push to make everyone upgrade to Windows 10, I've been loathe to give them my product key again.

Sorry about the delay, got my system back up and set up a backup image this time. Hopefully, next time I need to do a re-install, I won't face so many problems.

As for SDL_Sound, it looks like I've actually finished with the actual SDL_Sound library now. It works like its supposed to work. The problem seems to be somewhere in the DOSBox code. This week long re-install is finally over and done. Built the DAUM source code with my SDL_Sound and it works just like its supposed to work. MP3 format audio in the .cue files work just fine. Go back to DOSBox SVN build, with the exact same SDL_Sound library, and MP3 again produces no audio.

So, now it's tracing down what it is in the DOSBox code that keeps MP3s from playing as CD tracks. I'd rather not play cut-and-past from the DAUM build again to get it working. Though, it could be the

FeedingDragon wrote:

So, now it's tracing down what it is in the DOSBox code that keeps MP3s from playing as CD tracks. I'd rather not play cut-and-past from the DAUM build again to get it working. Though, it could be the

Did you build mpg123 into SDL sound?

In my build, MP3 isn't built in because I only built wav, ogg and flac, on account of not being able to get mpg123 to build.

Kisai wrote:

Did you build mpg123 into SDL sound?

In my build, MP3 isn't built in because I only built wav, ogg and flac, on account of not being able to get mpg123 to build.

I didn't use the built in mpg123 code, I had to build libmpg123 separately, then include like any other library (libFLAC, libVorbis, etc...) I actually fought with the build in libmpg123 engine for quite a while. I had originally thought that might be the problem, using a separate MP3 engine, but that turns out not to be the case 🙁 If you can't get the libmpg123 library to build, what environment are you building in? I use Visual Studio (only one I own, and can mostly afford to keep up.)

I had thought, maybe, to get better timidity functionality by doing the same thing with that (SDL_Sound doesn't support SoundFonts for example.) But am still fighting to get Timidiity to build at all. The frustrating point is, it looks like I'll have to switch to an older version of the Timidity source codes, the current one doesn't seem to provide the functions that SDL_Sound uses. Of course, Timidity++ isn't exactly clear on which package is the driver, and which is the engine, or what is needed to create a development package. Keep intending to play copy/build - set up a new project, and add in the same files from the Timidity source that SDL_Sound uses, then go from there.

FeedingDragon wrote:

Kisai wrote:

Did you build mpg123 into SDL sound?

In my build, MP3 isn't built in because I only built wav, ogg and flac, on account of not being able to get mpg123 to build.

I didn't use the built in mpg123 code, I had to build libmpg123 separately, then include like any other library (libFLAC, libVorbis, etc...) I actually fought with the build in libmpg123 engine for quite a while. I had originally thought that might be the problem, using a separate MP3 engine, but that turns out not to be the case 🙁 If you can't get the libmpg123 library to build, what environment are you building in? I use Visual Studio (only one I own, and can mostly afford to keep up.)

I had thought, maybe, to get better timidity functionality by doing the same thing with that (SDL_Sound doesn't support SoundFonts for example.) But am still fighting to get Timidiity to build at all. The frustrating point is, it looks like I'll have to switch to an older version of the Timidity source codes, the current one doesn't seem to provide the functions that SDL_Sound uses. Of course, Timidity++ isn't exactly clear on which package is the driver, and which is the engine, or what is needed to create a development package. Keep intending to play copy/build - set up a new project, and add in the same files from the Timidity source that SDL_Sound uses, then go from there.

Hmm, for some reason I said mpg123 when I meant SMPEG (the SDL_sound.h references mpg123), neither are compiled in. I just deleted them from the project file.

Here's the thing. Why bother building timidity when the only function SDL_Sound provides is playing music from the cd-rom cue sheet. Unless you're going to use your SDL_Sound build with something other than dosbox, you should just disable the formats that don't make sense to support. If you don't compile in SDL_Sound, you don't get cue-sheet audio tracks. That's it.

First, because I like to build things with full functionality in case I decide to use them in another project. Second, because I thought it might be interesting to build a cue sheet with MIDI music files replacing the audio tracks instead of digital music files. Not something likely to come up on a regular basis, maybe, but could be interesting. Also, if it's just music tracks, most MP3 files range from 5 to 10 MB each, while a MIDI file is usually around 5 to 10 KB. 5 MB of sample files (standard GUS sample set,) with 100 KB of MIDI files to replace 50 MB of MP3 files. That's for the Timidity that comes packaged with SDL_Sound. With full Timidity, that 5MB of sample files can be reduced to around a 2 MB SoundFont file (using the same samples, put through SoundFont compression.)

I'm currently taking a brief break, but will be working on 2 projects (3 if you count getting a fully functioning Timidity into SDL_Sound.) My current next step is to dig through the Daum build and DOSBox SVN to figure out why MP3 works in Daum but not in SVN. Second, to figure out how SDL was fixed to stop killing Aero on OpenGL, and fix that again (so I can use fresh build SDL instead of exported libraries from the working SDL.dll file I have now.) Then to see about expanding that fix to cover other modes (surface, overlay, & ddraw,) as well. Unless I can get MIDI (and MOD files for that matter,) working through SDL_Sound, working on Timidity isn't that high on the priority list. But it is still an interesting problem.

Finally, concerning Timidity, I had to dig through the code to figure out why MIDI was failing in the first place. I then had to dig through the code to figure out how to construct the needed config file to enable it. The base build of Timidity, it looks like, will build a basic config file for you (with instructions,) if it doesn't find one. That would have been very handy when I was trying to get Timidity working in SDL_Sound the first time around.