woof
woof copied to clipboard
fabiangreffrath
Audio issue on AmigaOS4 (big-endian)
We had just ported Woof 12.0 on AmigaOS4 (PowerPC)... no particular issue to report, but there is a problem with the audio. Apparently we can use SFX and no MUSIC, or only MUSIC without SFX. The reason is that If we start Woof by activating both, the game will start by after a while the game will freeze Unfortunely when it freeze, we doesn't either get any debugging information, we can still move the cursor, enter and / or exit the screen, but the system / screen has kind of frozen.
Any idea?
What do you use for music, Fluidsynth? What version of OpenAl-Soft are you using? You can try to select OPL emulation for MIDI player.
If i'm not mistaken actually we are using OpenAl-Soft 1.18 I just sent a bump to this thread to the programmer who did the port :-)
I'd also be interested in any porting issues that you encountered. Our code is supposed to be endianess clean, and also clean of any sizeof(long) or char signedness issues, so whatever was necessary to get it to compile on Amiga OS, please let us know.
Of course yes :-) For the moment there were no need for significant changes.. only this problem with the audio remains but we're trying to figure out what's causing it :-) Woof has recently been ported also to MorphOS PPC (another Amiga compatible system) and there don't seem to be any problems with the audio ... quite probably its something very specific, perhaps our OpenAL lib
oof has recently been ported also to MorphOS PPC (another Amiga compatible system) and there don't seem to be any problems with the audio ... quite probably its something very specific, perhaps our OpenAL lib
I have contacted the porter. The only things they changed were related to file path handling:
https://github.com/fabiangreffrath/woof/compare/master...BeWorld2018:woof:master
My only theory is problems with thread in i_oalmusic.c or a with OpenAL-Soft. I need Woof's terminal output or information about the selected MIDI player.
My only theory is problems with thread in
i_oalmusic.cor a with OpenAL-Soft. I need Woof's terminal output or information about the selected MIDI player.
There are some error paths in StartPlayer() and UpdatePlayer() that should probably reset the player_thread_running variable.
Log of running the game until crash:
Woof 12.0.0 (built on Dec 5 2023)
M_LoadDefaults: Load system defaults.
default file: ENVARC:/woof/woof.cfg
IWAD found: doom1.wad
DOOM Shareware version
V_Init: allocate screens.
W_Init: Init WADfiles.
adding doom1.wad
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [ ]..............
P_Init: Init Playloop state.
I_Init: Setting up machine state.
I_InitJoystick: Initialize game controller.
I_InitSound:
Using 'ahi.device' @ 44100 Hz.
Precaching all sound effects... done.
NET_Init: Init network subsystem.
D_CheckNetGame: Checking network game status.
startskill 3 deathmatch: 0 startmap: 1 startepisode: 1
player 1 of 1 (1 nodes)
S_Init: Setting up sound.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.
OPL_Init: Using driver 'SDL'.
S_ChangeMusic: D_INTRO (doom1.wad)
S_ChangeMusic: D_E1M5 (doom1.wad)
P_SetupLevel: E1M5 (doom1.wad), Doom nodes, Doom 1.9 complevel
G_DoPlayDemo: Playing demo with Doom 1.9 (109) compatibility.
SDL2: 2.25.0 vorbis: 1.3.7 FLAC: 1.3.2 ogg: 1.3.3
Statically linked on the AmigaOne system.
32 bit system.
===
Either of these options on their own work: -nosound -nosfx -nomusic
Once there is a need for music and sfx then the game will freeze. The length of time from start for the freeze to occur is random, but generally happens within 30 seconds; more likely within 10.
===
I do also need to change the paths for things too. As you can see: ENVARC:/woof/woof.cfg needs to be ENVARC:woof/woof.cfg. I doubt that this is a path issue though...
Perhaps you can suggest some printf debugging locations to test. BTW, I do notice that some structures that are used in the i_oplmusic.c file use packed structures. I believe this has caused some issues for us in the past.
===
On a side note: I did need to properly initialise SDL_TIMER to get this to work on the AmigaOne system. Firstly, I am not sure if I should be doing that since it is not done in the code; secondly, most other systems are a lot more permissive than AmigaOne - which requires proper init/destruction of SDL modules before finally quitting.
I do notice that some structures that are used in the i_oplmusic.c file use packed structures. I believe this has caused some issues for us in the past.
We also use packing in WAD code and other places, but the game runs without music.
I did need to properly initialise SDL_TIMER to get this to work on the AmigaOne system. Firstly, I am not sure if I should be doing that since it is not done in the code; secondly, most other systems are a lot more permissive than AmigaOne - which requires proper init/destruction of SDL modules before finally quitting.
Yes, on Windows almost no initiation is required for some reason. Also we use timer with nanosecond precision SDL_GetPerformanceCounter. I'm curious if it works properly on Amiga.
The issue is probably in i_oalmusic.c file. Try to increase delay here:
diff --git a/src/i_oalmusic.c b/src/i_oalmusic.c
index ce4e333..1c5a0d8 100644
--- a/src/i_oalmusic.c
+++ b/src/i_oalmusic.c
@@ -199,7 +199,7 @@ static int PlayerThread(void *unused)
while (player_thread_running && UpdatePlayer())
{
- SDL_Delay(1);
+ SDL_Delay(100);
}
return 0;
It's possible to remove that thread entirely.
@rfomin On a single test it seems to have progressed further than usual. I am using the 12.0 release + this patch: https://github.com/fabiangreffrath/woof/pull/1304.
Let me do some more testing / @samo790 I will send you a binary to test.
@fabiangreffrath Would you also consider a patch for proper init/de-init of SDL_TIMER?
On a single test it seems to have progressed further than usual.
But still a crash occurs? Alternatively, we can remove the music player thread completely and update the OpenAL stream in the main loop. But it works fine on other platforms, maybe the problem is in the OpenAL port?
There is no crash. But I have not extensively tested it. So far, your patch looks promising.
Can you just succinctly describe how you patch may have solved the issue?
Regards,
Can you just succinctly describe how you patch may have solved the issue?
I was sloppy with the music player thread when using the alSourceQueueBuffers API, since OpenAL is supposed to be thread safe. But maybe it was just luck that it works on other platforms. Using mutexes is the right approach, it prevents possible deadlocks.
@fabiangreffrath Would you also consider a patch for proper init/de-init of SDL_TIMER?
Yes, of course. I appreciate every portability fix.
@rfomin So your patch definitely improves things in so far as the demo / playing lasts a lot longer. But, eventually, it does freeze again. Can you possibly look into more, or provide some printf debugging that would help?
I've tried removing the music player thread here: #1320 The OPL3 emulation is quite heavy, we don't want it in the main thread. Does Amiga have multicore CPU?
I think we need to narrow it down. Try using the OGG music pack (just put it in autoload directory or run woof -file doom_sc55_ogg.zip). If you have built an xmp library, you can also try WAD with tracker music: idgames
@rfomin we only have an old port of Chocolate Doom (2.2) http://os4depot.net/?function=showfile&file=game/fps/chocolate-doom.lha
we only have an old port of Chocolate Doom (2.2)
I'm asking because it's not clear where the problem is, in the OpenAL streaming or in the OPL emulation. Please try the other music formats I mentioned in the https://github.com/fabiangreffrath/woof/issues/1285#issuecomment-1849376078
PR #1320 patch which removes the sound thread seems fixing the issue under AmigaOS 4, no more freeze when using audio + music :-)
PR #1320 patch which removes the sound thread seems fixing the issue under AmigaOS 4, no more freeze when using audio + music :-)
Have you tried other music formats without PR #1320?
@rfomin With the old binary by starting from shell with woof -file doom_sc55_ogg.zip i can see the ogg files loading, but as soon as it reach the intro screen it just freeze :-( Instead with latest binary that include PR #1320 everything works
Btw, ogg files are inside a music folder, if i want to load them automatically instead of via shell, do i need to just copy that "music" folder into autoload dir, or they need to be extracted first?
So, this appears to be a general threading error on either the OS or openal-soft side. Since literally no other system has ever shown up a bug like this, it would be interesting to see what difference an updated openal-soft library would make.
Btw, ogg files are inside a music folder, if i want to load them automatically instead of via shell, do i need to just copy that "music" folder into autoload dir, or they need to be extracted first?
Extract *.ogg files to autoload/doom.wad directory. Thanks for testing!
So, this appears to be a general threading error on either the OS or openal-soft side.
I have a theory that there is a faulty track switching sequence. I will try to come up with a patch later.
@rfomin Thanks, copied them on autoload/doom.wad folder and works! Btw, i just opened a (possibile) bugreport in our OpenAL repository, let's see what comes out :-)
@rfomin Thank you for the effort, but we still get a freeze eventually.
With #1320 we have something that works. If you want me to consider any other changes then I can try them. I am just interested in getting a port out for AmigaOS4 so I am not invested in finding the root cause.
@fabiangreffrath The following are the full set of differences that I made compared to the main repository at TAG 12.0.2. You may or may not be interested in the various cleanups that I needed to perform in order to prevent leaking memory on the AmigaOne machines.
I seem to have to append .txt for github to allow me to upload it.