@Hans and BSzili In protect the SDL code: but we have a lot of sdl and sdl+opengl apps/games, where is no such problems with fps drop when it used with or without audio. I mean, if SDL are root case, then problems should happens in every sdl+opengl game/app.
We've seen in the last couple of years all sorts of interesting projects on Kickstarter which aren't very demanding graphics-wise and could run on most systems. The most recent name that comes to mind is Thimbleweed Park (old scholl pixelelated point and click) by Ron Gilbert. Gilbert was never actually an amigan even if his best versions always came on the Amiga. He always talks in his blog about retro gaming and his love for old games and pixelated games. Wouldn't it be great to do a port on release? he can say that a port for AmigaOne is being made which could in turn make people look at it as a potentially new Monkey Island level game.
@Srtest Don't be fooled by the looks, a lot of these games are built on top of modern technologies (programmable shaders, etc.) to make use of the GPU. It could use a proprietary closed source engine, or middleware. Anyway, if you can negotiate a deal with Ron Gilbert and Gary Winnick and there are no technical barriers, I could probably do the port.
Edited by BSzili on 2015/4/22 8:37:48
This is just like television, only you can see much further.
In protect the SDL code: but we have a lot of sdl and sdl+opengl apps/games, where is no such problems with fps drop when it used with or without audio. I mean, if SDL are root case, then problems should happens in every sdl+opengl game/app.
Not necessarily. Different games use SDL differently, so it's very possible for many games to have no trouble, while one or two do. I don't know exactly what runs in SDL's audio task, so I can't say for sure.
Obviously, the root cause could be Homeworld's audio code, since it is the only SDL game to exhibit this behaviour. SDL on other OSes don't set the audio task's priority so high, possibly because those OSes have a fairness algorithm that can help ensure that it still gets enough CPU time. So it's quite possible that Homeworld's audio code somehow expects a certain delay until the audio task gets the CPU again.
Whatever the case, I think that an audio task priority of 15 is escessive. That's higher than some important OS tasks, including device driver tasks.
The buffer refill callbacks are run in the SDL audio thread.
And what happens when that code gets CPU time but the buffers are already full or there isn't any new data?
Incidentally, where is the audio mixing done? In a separate task?
I did some profiling of the W3D_SI driver, and when audio is enabled in Homeworld then certain operations that should be done within to several microseconds get delayed by up to 0.1-0.2 seconds! When the audio driver is disabled then things drop back to normal.
As you've said it's not a problem on other platforms, because 1) they don't set a very high priority for the SDL audio thread, that could potentionally interfere with system processes 2) they potentially have more sophisticated scheduling.
This is just like television, only you can see much further.
I did some profiling of the W3D_SI driver, and when audio is enabled in Homeworld then certain operations that should be done within to several microseconds get delayed by up to 0.1-0.2 seconds! When the audio driver is disabled then things drop back to normal.
@afxgroup I didn't ask that because I doubt your capabilities, but because the version you've sent me lacked any big-endian fixes in the mixer, streamer, sound code, etc. The one I worked on has almost 100% functional sound, but the random unit speak trashes the mixer's memory. If you want to revisit Homeworld at any time, I can send you my version, maybe you can figure out what's going on there.
This is just like television, only you can see much further.