Coughing Caused This App To Segfault

Users are great at identifying that there is a problem. Something is wrong here, but maybe not what the problem actually is, why it's there, or better yet, how to actually go about fixing it. One such case is coughing in my microphone causes a segfault. This was reported and fixed back in 2013, but I recently saw this circulating around and obviously with a title like that, we have to talk about it. This is reported on a project called Performous, which actually is still being worked on to this day. As is on the GitHub, this is an open source music and rhythm game. An open source karaoke, band, and dancing game, where one or more players perform a song and the game scores their performance. Supports songs in Ultrastar, Threats on Fire, and Stepmania formats, microphones and instruments from SingStar, Guitar Hero, and Rock Band, as well as some dance pads, are order detected. Basically, it is an open source implementation of SingStar, Guitar Hero, and DDR, all in basically one package. So of course, for a game like this, sound is going to be very important, and because there are microphones, sometimes sound input is gonna lead to some sort of bug. Now, obviously, coughing wasn't what was causing the seg fault, but this is the sort of replication condition the user came up with. Now, that's one weird issue. I mostly use, for now, Performous' training feature, read the microphone's pitch, and show it on a sheet. This tool is used to be even creating song files with Composer alongside, as seen in a semi-related issue report on Composer's GitHub page, which, annoyingly, is not actually linked here, and I wasn't able to go and find it, because it's an issue from 13 years ago. Now, the mic being used wasn't something like a SingStar mic. My microphone is actually a throat microphone. This allows me to keep my hands free while working, and minimize external noise impact. This is basically a little band that goes around your neck, and then, rather than listening to the sound that comes out of your mouth, it actually listens to the vibrations, like, directly coming from your neck. This is something most people are not gonna be using, but if you need to operate in a completely hands-free situation, and you're not able to do something like this, where you have a mount for the microphone, or you're in a situation where listening to the sound coming out of your mouth would sort of distort the sound, and you want to have something that's able to sort of, like, get rid of a bit of that background noise, that's one way to go about it. Now, obviously, having a microphone on your throat is gonna sound very different to the sound coming out of your mouth, but if your goal is to get sound, it's definitely a way to do so. However, it tends to over-amplify some sounds, such as coughing or scratching near the throat. In such cases, Performous tries to analyze the pitch and draw notes on the screen, fails, and segfaults. When launched in a terminal, the error is reported as terminate cold without an active exception. This might be a hint regarding how Performous handles the microphone inputs. I doubt this could appear in-game, in regular play situations. The input usually isn't that aggressive, and this was reported on Ubuntu 1204. Again, this is from 2013. Now, annoyingly, that error reported in the terminal, this is not really accurate to what is actually happening, and I can see why this would lead you down some weird route about it segfaulting, when that's technically not what actually happened here. Now, the fact that it's crashing on a really loud sound should give you some sort of indication on what is actually happening here. It is an application that is supposed to be drawing a pitch line. You go above a certain level of volume, and then the application is like, I don't know what this sound is. I'm just going to die now. Obviously, coughing isn't what is causing the segfault, but if you have a microphone on your throat and you cough, that's a pretty good way to have a really loud sound. To be extra certain that coughing isn't the cause, someone said, this might be an issue with drawing the practice screen, as no one has encountered anything similar in-game. However, I couldn't make it crash by coughing, shouting, and growl, into a regular headset microphone. So possibly, it's something weird about this specific microphone. Could you provide a backtrace from the crash with the GDB debugger, and that explains how to go and do that. In that log is just normal various log things, and then down the bottom, notably when it crashes, not a segfault, it says, fatal error, musical scale, get note, invalid frequency. This isn't a segfault

this is their actual self-defined fatal error. So whilst it was saying, okay, terminate code without an active exception, it actually did crash with an error defined by the application. The dev version has touched the code that produced the error, and is likely already fixed. Can you compile Performous from Git and test? Compiled from Git, Performous won't let me open any sound device now for some reason, can't record, nor output anything. We'll investigate later. Correction, audio output okay on system default, which is the only device working. Input still does not even work on system default, pulse audio is set up correctly, default microphone works at the system level. So it at least appeared to be not an issue with the user's configuration of their system, which especially at this time back in 2013, you know, pulse audio had this sort of reputation of pulse audio breaks your sound, sound doesn't work on Linux, you go to YouTube to watch a video on how to fix your sound, things like that. That at the time was a very common thing, and at least here, didn't appear to be the problem. Now here's where we get to the actual problem. Performous didn't just support Linux. It also had a Windows and a macOS version as well. And when you're dealing with sound, there are two main ways to do so cross-platform. One, you basically do everything yourself. You have native library integration for all of the different systems you're going to be using. Pulse audio on Linux, or I guess nowadays you use Pipewire. You'd have whatever Windows uses, you'd have whatever macOS uses, and manage all of those relationships yourself. Now, this is complicated, this is hard, and a lot of people don't want to do so. So instead, what a lot of people do is they rely on some cross-platform library that does that abstraction for them. And that is exactly what was being done with Performous. I suppose that we are incompatible with pulse audio input because we asked for such a small buffer size. Port audio suggested latency setting. Technically, this is a port audio bug. It should either choose the smallest available size or offer an API for finding what the minimum is. Also, it should directly support pulse audio, which is something that it doesn't currently do. So it uses that ulcer API instead, leading to this problem. And the fact that port audio releases a new version about once in a decade doesn't really help. So this right here is port audio. Port audio is a cross-platform, open-source C language library for real-time audio input and output. And basically what it's doing is just abstracting away those OS-level audio libraries and giving you one consistent interface to interact with. Now, most of the time this would be fine because when there is a bug, you're going to have a bug fixed and things are going to go well. As you can see, development is still somewhat happening in this project. It's, you know, not the fastest thing out there, but it does happen. And this is in 2026. When was the latest release? From now. 2021 is the latest tagged release. So this happened in 2013. And even back then, it had a reputation for basically never releasing a new version. That hasn't changed. They're still doing the exact same thing. It was entirely possible that at the time this bug was reported, the bug had already been fixed for like three or four years. And there was just no way to know the bug was fixed unless you're running the dev version. And you shouldn't have to run a dev version for the updates to be within the last, you know, five years. The best workaround that I can think of is changing the latency request when Pulse or Default is chosen. In the past, we use platform-specific audio APIs directly, but that was painful to maintain. So in the past, they weren't using Port Audio. Instead, for each of the operating systems they supported, they were directly interacting with whatever audio system they were using. So, OSA, Pulse Audio, Pipewire, and again, whatever the hell it is that Windows and Mac OS uses, nobody knows, nobody cares. Port Audio provided a nice portable API and it worked on our target platforms. Too bad they also made their last release in 2011 even though there are a number of bugs. So the latest release as the reporting of this bug, as the fixing of this bug, was two years prior. Again, you shouldn't have to run a dev version to have any of the fixes, any of the features, changes that were added in the past two years. That's not how you should be running a project. Tag it somewhat more often. In most cases

it is best to assume that any bugs in your project are caused by you and not caused by libraries you rely on. Now, of course, libraries you rely on can have their own bugs, but typically, it's going to be your own problem. However, even if it is a bug in an upstream library, if the bug hasn't been dealt with, if the latest release was two years prior, it's still your bug, right? Even though it's not in your project, you still have to code around the bug. So that was fixed in this commit here, 94C632A. Audio bug fixing and cleanup should, I like that, should fix the problem reported in bug number 38, pulse audio not working. Not relevant to the issue we're talking about today, but something slightly bothering me in the code is there's just like a random go-to here. And I assume if there's a random go-to here, there's probably random go-to's in other parts of the code as well. I, I always question whenever I see a go-to, I'm sure they have a reason for it. There's probably some sensible reason for it. Also, the way this code is written is disgusting. Why do you, why do you have a for loop and an if statement and the go-to on one line? Don't write code like, just, don't write code like this. The compiler doesn't care if there's multiple lines. Now, I had thought that maybe this issue got referenced in a more recent problem because there is, uh, this right here. Mention on February 24th, 2020, crash on Fedora 30. This actually wasn't a mention. What this was, was someone went and, uh, posted a log right about here. And, uh, these hashtags, they, uh, pound signs if you're old. Uh, when there's a number next to them on GitHub, it will go and reference the issue that is associated with that number. So, everything from 1 to 43 just randomly gets tagged by this issue. So, this was a dumb little issue and, like, every time this happens, eventually gets discovered by Reddit and social media and then people start spamming comments on here because they don't know how to just, like, comment in the place that allows comments. So, eventually this did get locked, which it should have been done from the start because, you know, obviously this was eventually going to happen. But, I don't know. I like issues like this. I like these weird, old issues that, you know, don't necessarily make immediate sense why they're happening and are just, I don't know, they're just kind of fun. It's a nice change from any of the serious stuff we talk about. Granted, we don't talk about that much serious stuff, so it's a break from the little bit of serious stuff we sometimes talk about. Anyway, if you have some dumb, random issue you want me to take a look at, please send it my way. The dumber the better, the older the better. Please let me know because I'm sure there are plenty out there that nobody's ever really thought about. So, I guess, if you like to have some fun, go like the video, go subscribe as well. Let me know your thoughts down below. If you like the video, I said that, like the video, subscribe, yeah, I did that already. If you really like the video and you want to become one of these amazing people over here, check out the Patreon, SubscribeStar, Liberapay, link in the description down below. That's going to be it for me and, hear me sing.