Issues with multiprocessing and audio reproduction with a Linux game

I'm needing a bit of general knowledge in audio and multiprocessing applications in Linux here.

I've got a game made for Arcade use and I'm trying to run the game in my own Linux (Mint 19.3). Its original Linux is Debian 9 with a i686 PAE kernel, but it doesn't work in any of my computers because it lack drivers for them.

Making it run wasn't very difficult, I just had to install the i386 libraries it tried to open (which I verified running it with strace).

The only problem is that while running, the audio a bit choppy, it has a few brief clicks and cuts like a scratched CD playing and skipping.

The application uses libasound2, and communicates directly with the ALSA system, it doesn't need pulseaudio (and I removed it just to make sure it wasn't causing any conflicts, but it didn't make a difference either).

The application is by far very light for my hardware, using only 30% CPU at most (adding all cores together), and 20% GPU, so it didn't make sense it was happening due to anything not being fast enough (which I have experienced before when trying some real-time audio processing plugins for pulseaudio).

I tried a lot of things, like changing the priority of the IRQ thread of tied to my soundcard (IRQ 16), unloading other driver modules tied to the same IRQ (like the wifi driver), and preventing the IRQ thread and game from sharing CPUs (by changing the game affinity to other CPUs).

Nothing helped.

Then I tried to go the other way: Trying to make it worse.

I tried setting the game affinity to the one CPU that was processing the IRQ 16 thread and it solved the issue.

However, it solved not because it was in the same CPU as the IRQ, but because it was in a single CPU. Setting its affinity to a any single CPU solves it. And this same behavior happens when I run the same OS and game in different hardware, with different CPU and GPU brands, it's a constant.

I know its original hardware uses an Intel Celeron L420, it has no multithreading and a single core (which makes me wonder why the game itself supports multiprocessing and runs on my 8 threads evenly).

But it seems like its original Debian 9, which as far as I know supports several cores normally without having anything to restrict it at any point, runs the game smoothly even in some multicore CPUs, because others have done that.

Am I missing anything here?

I've tried literally copying all the original libraries from the original game OS into my OS (forcing it to load them and checking if they were loaded with strace), but that changed nothing.

I'd expect that if this was an issue in the game programming, it should always happen in whatever Linux as long as it runs in several CPUs instead of one.

Any idea of what could be happening here?

Or what else I can look for in order to debug this?

There is almost NOTHING that is uniform throughout gaming programming. Just looking at the number of game engines that COULD be used to get a glimmer. Most game development these days starts with a game engine (That may or MAY NOT be available to the public) and then gets "adjustments and modifications" to better support the development of that game project. Sound support and threading support vary greatly, and in multiple ways.

You found a solution for your specific issue for that specific game, and I am VERY glad!
Be aware that the same symptoms may or may not respond to the same solution for a different game.
I might have tried running a real-time kernel, but I suspect your solution is better.

If you're needing i386 libraries, we're talking the lase millenium? Name the games, or the better known ones, to be sure. Pcs then had a lot of kinks, and software layers have been written the different way hardware was due to the myopic hardware design.

I'm no gamer, but I did install Space Quest here, and had to install the compatibility layer. It's a pisstake on Star Trek. Forget the name, but I also had to put in two sound packages for midi files. Search the web for running old stuff if it doesn't come up.

The shared insights and troubleshooting tips truly showcase the collaborative spirit of the Linux community. It's inspiring to see how members come together to support each other in overcoming challenges and maximizing system efficiency. Speaking of optimization, have you explored the APK options for enhancing your Linux experience? Check out apk1xbet.in for a seamless journey into a world of possibilities. Keep the positivity flowing, and let's continue empowering each other to reach new heights in our Linux endeavors!

Originally Posted by wpeckham There is almost NOTHING that is uniform throughout gaming programming. Just looking at the number of game engines that COULD be used to get a glimmer. Most game development these days starts with a game engine (That may or MAY NOT be available to the public) and then gets "adjustments and modifications" to better support the development of that game project. Sound support and threading support vary greatly, and in multiple ways. You found a solution for your specific issue for that specific game, and I am VERY glad! Be aware that the same symptoms may or may not respond to the same solution for a different game. I might have tried running a real-time kernel, but I suspect your solution is better.

Thanks, I'm aware of how specific and particular this solution is.

But rather, I was asking for what else could I try to debug and find a better particular solution for it, just like the idea you have me of using a real-time kernel.

I thought about switching to a low-latency kernel, but the reason I haven't tried it yet was, besides having to recompile DKMS drivers, the fact that its original kernel isn't low-latency to begin with.

That's why I figured this solution was probably not the best one.

But its original kernel is also different in the sense of being a PAE i686 kernel instead of an amd64 kernel. And perhaps it was compiled with different options regarding scheduling that I don't know about.

But I never actually made sure that its original OS can in fact run in a multiprocessor without causing those same issues, perhaps the same will happen and it was never an issue with the OS.

Originally Posted by business_kid If you're needing i386 libraries, we're talking the lase millenium? Name the games, or the better known ones, to be sure. Pcs then had a lot of kinks, and software layers have been written the different way hardware was due to the myopic hardware design. I'm no gamer, but I did install Space Quest here, and had to install the compatibility layer. It's a pisstake on Star Trek. Forget the name, but I also had to put in two sound packages for midi files. Search the web for running old stuff if it doesn't come up.

The game is Pump it Up Prime 2, from 2017. Andamiro isn't exactly known from being very up-to-date in their software.

I'm not sure about their newer two versions, but I'd make a bet that even the 2023 Phoenix relies on i386 libraries.

And one thing I know, their latest, most up-to-date hardware is still single-core single-thread.

Originally Posted by guferr The game is Pump it Up Prime 2, from 2017. Andamiro isn't exactly known from being very up-to-date in their software. I'm not sure about their newer two versions, but I'd make a bet that even the 2023 Phoenix relies on i386 libraries. And one thing I know, their latest, most up-to-date hardware is still single-core single-thread.

This sounded very confusing. So I looked it up. It's an ARCADE GAME to run on old arcade game machines, not modern PCs. They are for amusement arcades - beside one armed bandits and bumper cars. I don't have specs from those arcade machines but wikipedia has an article on PIU Prime. I reckon they are ≅1990 designed arcade machines. Between 1985 & 1994, we had '386, '486, & pentium. Arcade machines apparently ran on 480p, = 640x480 which was where things were at in vga video back then.

Some of those arcade machines evidently forgot to die, apparently. Maybe they have zombie or museum piece status? But sure, you can turn your modern pc into a zombie antique arcade machine. There will be some loss of quality and function as layers of emulation will be necessary. But there's plenty of enthusiasts online, so web searching should be fruitful. I'm not one of the enthusiasts, I hasten to add.

EDIT: These things actually might actually predate linux so dosbox might be the way to go.

Originally Posted by business_kid This sounded very confusing. So I looked it up. It's an ARCADE GAME to run on old arcade game machines, not modern PCs. They are for amusement arcades - beside one armed bandits and bumper cars. I don't have specs from those arcade machines but wikipedia has an article on PIU Prime. I reckon they are ≅1990 designed arcade machines. Between 1985 & 1994, we had '386, '486, & pentium. Arcade machines apparently ran on 480p, = 640x480 which was where things were at in vga video back then. Some of those arcade machines evidently forgot to die, apparently. Maybe they have zombie or museum piece status? But sure, you can turn your modern pc into a zombie antique arcade machine. There will be some loss of quality and function as layers of emulation will be necessary. But there's plenty of enthusiasts online, so web searching should be fruitful. I'm not one of the enthusiasts, I hasten to add. EDIT: These things actually might actually predate linux so dosbox might be the way to go.

If you like hardware, you could use a SBC and FreeDOS (and i386 or X86_64 SBC will be overkill) to build an arcade machine to emulate the originals. Someone smarter than I might even use a RPi as a core!

An RPi is a poor choice imho as it's endianness is wrong. The arcade thing could be 16/32 bit, and the Pi 64bit.

I was a hardware guy, but not any more. There seems to be plenty of old crap owned by users on these forums. But you would have to try a 32bit box, as 64bit interpreting 16bit software I haven't heard of.

We'll see. The OP will probably web search & report back.

Originally Posted by business_kid This sounded very confusing. So I looked it up. It's an ARCADE GAME to run on old arcade game machines, not modern PCs. They are for amusement arcades - beside one armed bandits and bumper cars. I don't have specs from those arcade machines but wikipedia has an article on PIU Prime. I reckon they are ≅1990 designed arcade machines. Between 1985 & 1994, we had '386, '486, & pentium. Arcade machines apparently ran on 480p, = 640x480 which was where things were at in vga video back then. Some of those arcade machines evidently forgot to die, apparently. Maybe they have zombie or museum piece status? But sure, you can turn your modern pc into a zombie antique arcade machine. There will be some loss of quality and function as layers of emulation will be necessary. But there's plenty of enthusiasts online, so web searching should be fruitful. I'm not one of the enthusiasts, I hasten to add. EDIT: These things actually might actually predate linux so dosbox might be the way to go.

Well, you're clearly not used with their hardware nor software, but I am, and honestly you're only making further confusion with this thread.

Their current hardware is old, but not that old. Mostly 2010 specs, but it's fairly basic. The processor of their latest hardware version (which has been around for over 8 years) is Intel Celeron L420 1.6GHz, a 64-bit processor. They don't use a 64-bit OS because they just don't want to.

Also, their game is 1280x720 in resolution, and its native OS is a Linux. Only their first versions in the early 2000s used DOS, ever since they've used RedHat, Debian and Ubuntu in their versions (and for some reason they develop on Windows, but then port the final version to Linux, go figure).

But absolutely no emulation is necessary, many many people have been running them on newer hardware, with the native OS, but using old video cards, because it only have drivers for really old nvidia cards, despite a wider compatibility with chipset, processors and audio cards.

And I *think* (I didn't confirm though) they didn't have had any audio issues as I'm having, and again, I'm having the same issue across various different hardware I tested, some of which is over 10 yo, and in all of them the solution is forcing single-threading.

So I guess that the issue is that they've never focused in multithreading, but some why they made a game that can run with multithreading, and automatically tries to do so. Probably something related to its engine.

The whole reason why I think there's something I missing is the fact that, supposedly, its native OS can run on multiprocessor CPUs without issues.

Either that or all other people who did this are deaf and didn't hear these annoying pops and clicks.

Well, I'm glad you're familiar with the hardware. You posted an issue about a dated arcade machine with no hints as to the spec or even if it was x86 based. I think it's a bit rich to accuse me of causing confusion! You had the information but didn't share it, so I had to guess.

RE:

The whole reason why I think there's something I missing is the fact that, supposedly, its native OS can run on multiprocessor CPUs without issues.

Dude, MS-DOS or FreeDOS can run on the latest X86_64 multicore multithreaded processor. There are operating systems written entirely in Pascal designed for i386 and up that run fine, one I use (KolibriOS) in Assembler. Almost any OS can run on multiprocessor CPUs without issues. If the OS or application is built for a slower and single threaded single core processor they trick is getting it to SLOW DOWN so it does not trip over its own code!

If it is designed well that is not an issue. For some reason many games do not get that part right.
I see no reason to suspect that as an issue in this case.