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...

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...

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.

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...

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.

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...

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.

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.

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.

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.

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!

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?

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.