Issues with multiprocessing and audio reproduction with a Linux game
by guferr from LinuxQuestions.org on (#6J0M5)
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?
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?