So it turns out the binaries I have aren't loading the acodec dependencies. Too bad! No sound for you!
Having somehow avoided building Allegro from sources in Windows since at least as far back as 2015, and since having at some point reclaimed all the space doing so robbed from my paltry 250GB SSD, I'm not looking forward to the prospect of having to re-download and install all that's needed and build every single last dependency along with, just to make certain I don't have to dive into this territory again until the next time I have to upgrade to get the fix for a showstopping bug.
Could someone who's already generated Win32 binaries of the dependencies of 5.2.2.x kindly help me out? Binaries would be just fab. Or the simplest possible path to accomplishing my goal of building them as fast as possible and getting back to working on games and stuff...
If you don't mind upgrading your compiler, I've got all the dependencies of Allegro 5 built plus more in my binary distributions. See the thread below for details :
Thank you! But, my bad, I forgot to mention, I'm using the dynamic binaries, so I need all the dynamic dependencies! Do you have those?
EDIT: Plus a dynamic binary of Allegro that will load them...
Yes, everything is included. static and dynamic versions of everything (enet, flac, freetype2, libpng, zlib, physfs, turbo (libjpeg), ogg, theora, vorbis, dumb (static only)). As well, there are dynamic debugging executables, demos, and tests, as well as html and chm docs and all the includes and libs you need for everything.
Oh! Money. 
I don't want to bother you, but can I contact you any time I need binaries in the future? This is a thing I'd like to not have to worry about anymore if possible.
I make a new release every time a new version of Allegro comes out. I have no plans to stop doing so in the future. And I fix bugs as they are reported.
Sounds good. Thanks for performing this service.
Unfortunately it didn't seem to work, I'm still getting null from al_load_audio_stream. Groan...
Try ex_stream_file. It's included in the examples. Run the .bat file in the root folder of the allegro binaries and then run ex_stream_file your_sound_file.ogg.
I tried a couple mp3's. Both threw error "could not create stream"
I tried a mod file as well. It actually hung up and after a while crashed.
EDIT: the mod file didn't work but an XM file did. and so did an ogg file. so mp3 isn't supported... makes sense; patents.
There's bound to be an .mp3 player for Allegro 5 out there somewhere.
It's totally legal to decode mp3s, just not to encode them without a license.
Edit
Sounds like allegro's audio addon could use a little more error checking.
Still not able to stream an ogg file in my project; I'm tearing my hair out, seems like this happens every time I upgrade. I even found a bug where somehow the file string was being clobbered. Will keep trying...
If you step into al_load_sample or al_load_audio_stream you might be able to find out why it's not loading.
Other things to check :
Initialize the acodec addon.
Make sure you have all the dlls in the right folder or on your %PATH%.
I am initializing the acodec addon. I am also in the folder with all the DLL's both when the Allegro DLL is loaded and when I call the al_init_acodec_addon function.
Boy I kind of wish I could step into it right now! Some detailed error reporting in this case would be VERY helpful. I just want to know if the dependencies were loaded or not.
Boy I kind of wish I could step into it right now!
Why can't you?
Here's gdb, grep, patch, and diff. Just extract and copy the contents of bin into mingw/bin. Use gdb to step into the functions.
This is all Greek to me. Due to a distaste for / lack of aptitude for the C multiverse and a strong will I have managed to weasel past the complexity and I just use SwiftForth and DLL's. That's it. Will gdb work with any EXE, even if it's not in C? (Not that I hold out much hope.)
I managed to get Process Explorer to show me what DLL's are loaded by my process. Looks like everything is there. I am literally doing just (the equivalent of) this...
al_init()
al_init_acodec_addon()
al_install_audio()
foo = al_load_audio_stream( path, 2, 2048 );
and foo is null. double triple checked everything.
Okay, well I didn't know you were using SwiftForth. Try compiling it as a C program first.
set path=c:\mingw\bin;%PATH% cd program_folder g++ -Wall -g -o test.exe -Ic:\allegro5\include test.cpp -Lc:\allegro5\lib -lallegro_monolith-debug.dll set path=c:\allegro5\bin\dlls;c:\mingw\bin; gdb test.exe break test.cpp:LINE_NUMBER run bt
I will give that a try. Just succeeded in loading a WAV file on a whim.
UPDATE:
Decided to try a faster way first. I enabled the debug binary, and checked out allegro.log. Here is the output:
stdio D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109 file_stdio_fopen [ 0.00000] opening C:\Users\Roger\Dropbox\Programs\SwiftForth_3.5.3\SwiftForth\bin\allegro5.cfg r system D E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:771 _al_win_safe_load_library [ 0.00000] PathFindOnPath found: C:\WINDOWS\system32\shcore.dll system D E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:682 load_library_at_path [ 0.00000] Calling LoadLibrary C:\WINDOWS\system32\shcore.dll system I E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:685 load_library_at_path [ 0.00000] Loaded C:\WINDOWS\system32\shcore.dll system I E:\LIBS\LIBS71Build\allegro\src\system.c:257 al_install_system [ 0.00000] Allegro version: 5.2.3 (GIT) audio-dsound I E:\LIBS\LIBS71Build\allegro\addons\audio\dsound.cpp:255 _dsound_open [ 0.00028] Starting DirectSound... audio-dsound D E:\LIBS\LIBS71Build\allegro\addons\audio\dsound.cpp:264 _dsound_open [ 0.04107] DirectSoundCreate8 succeeded audio I E:\LIBS\LIBS71Build\allegro\addons\audio\audio.c:347 do_install_audio [ 0.04522] Using DirectSound driver acodec I E:\LIBS\LIBS71Build\allegro\addons\acodec\ogg.c:204 _al_load_ogg_vorbis [ 0.04537] Loading sample ../../../temp/asdf.ogg. stdio D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109 file_stdio_fopen [ 0.04539] opening ../../../temp/asdf.ogg rb system W E:\LIBS\LIBS71Build\allegro\src\win\wsystem.c:775 _al_win_safe_load_library [ 0.04764] PathFindOnPath failed to find libvorbisfile-3.dll acodec W E:\LIBS\LIBS71Build\allegro\addons\acodec\ogg.c:97 init_dynlib [ 0.04770] Could not load libvorbisfile-3.dll acodec I E:\LIBS\LIBS71Build\allegro\addons\acodec\ogg.c:204 _al_load_ogg_vorbis [ 0.04777] Loading sample ../../../temp/mus_mode.ogg. stdio D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109 file_stdio_fopen [ 0.04779] opening ../../../temp/mus_mode.ogg rb stdio D E:\LIBS\LIBS71Build\allegro\src\file_stdio.c:109 file_stdio_fopen [ 0.04792] opening ../../../temp/palmroad.wav rb wav I E:\LIBS\LIBS71Build\allegro\addons\acodec\wav.c:107 wav_open [ 0.04809] Ignoring chunk: smpl wav I E:\LIBS\LIBS71Build\allegro\addons\acodec\wav.c:107 wav_open [ 0.04811] Ignoring chunk: JUNK dtor D E:\LIBS\LIBS71Build\allegro\src\dtor.c:196 _al_register_destructor [ 0.04820] added dtor for sample 1F4AD228, func 6788375D
Looks like libvorbisfile-3.dll fails to load, due to PathFindOnPath failed... but I'm in the same directory as that file. Makes no sense.
I have updated my Allegro version number that I pass to al_init to 5.2.3, thinking that was it. No luck.
Another update: Just tried copying all dependencies to C:/windows, and it succeeds. The heck.
Update the third: Tried copying them to the folder where my actual IDE's EXE is located. That worked too. I'm starting to think that this is a Windows 10 security thing. Disallow loading of DLL's that seem to be not related to the current process.
When a DLL is loaded, the %PATH% is what is searched, starting with .\. That means the current working directory needs to be the same as the one with your exe and dlls. Do NOT put DLLs in system32 or SysWow64, or any other system directory unless they're never going to change or very infrequently.
I seem to recall it being possible to compile all the dependencies into the allegro DLL. I think I did this to clean up the install directory of The Lady, a few years back. Would it be easy for you to do? Seriously I would paypal you $20 to avoid having to do it myself.
Uh, I would have to do it manually, and then it would be a static library. I'm not sure that's what you want.
Well, I could probably make it dynamic, but I don't remember the linker incantations to do so. It might take me a while, and I'm not sure why you need it.
Two reasons...
The framework I've built (Bubble) is loaded into the IDE, which is an EXE in a different directory. The IDE is the compiler. We load and test application code interactively here, and sometimes spit out an application exe. The issue is that I had to put in a notice telling people to copy all DLL's to the IDE's bin folder if they want sound. Not a show stopper, but it is a weak point; a person can forget to do that when I release the framework with new versions of Allegro.
The other reason is just my sense of tidiness. 
I leave it totally up to you if you feel like doing it. I wasn't kidding about paying!
There's probably some kind of licensing issue when cramming all those libraries into a giant glob like that.
DLL distribution is nothing new. Do you not have the option of static linking? How does the SwiftForth Allegro interface work? Are you loading the DLLs at runtime in your SF program?
Your IDE should have an option to select the current working directory. That is where the DLLs should be located.
Newp, no static linking, though in theory it could be done, at that point you're replicating GNU, haha.
I think the SwiftForth FFI just saves the Forth CPU state, creates a stack frame and calls DLL functions and then reverses the process to come back to Forth. Pretty straightforward. I do not have to load any dependencies of Allegro manually, I believe it is automatically done by Allegro's behind-the-scenes C stuff when I initialize. I just declare Allegro and SwiftForth takes care of loading it, in a similar fashion to C.
By "select the current working directory", what do you mean exactly? Like chdir? Or is there something else, like a WINAPI function I should call?
Yes, the following code will allow you to set the current working directory to the directory the executable is in. Use al_change_directory instead of _chdir or chdir. It takes care of the cross platform stuff for you.
Untested... but I've done this before so it's got to be close
/** #include "direct.h" */ //... ALLEGRO_PATH* p = al_get_standard_path(ALLEGRO_EXENAME_PATH); al_set_path_filename(p , NULL); /** _chdir(al_path_cstr(p));*/ al_change_directory(al_path_cstr(p)); al_destroy_path(p); p = 0;
I will try it but I don't think it solves my problem of having to put the DLL's in SwiftForth's folder instead of being able to just keep them packaged in my framework's libraries subfolder.
Well, they have to be in the current working directory, or on your %PATH%. That's all there is to it.
Edit
Actually, nevermind what I said earlier about changing the run time path. That won't affect the loading of dlls. When you link them to your program, they are set to load in the global start up before main as far as I know.
I statically link and Allegro 5 works fine. There was a minor problem Edgar fixed where you needed the DLLs even for statically linked audio. When I copied the DLLs into my executable directory it worked at that time. Edgar has since fixed this, but it did show me that it worked. But they need to be in your path or in your executable folder. I don't keep DLLs in my own path ever as I need to know which ones are required and if I forget to add one, I want that error to happen. So I always keep them out of the path and just copy the ones needed into the executable folder.
Neil, as I understand it he needs dlls for the Swift/Forth interface.