[Suggestion] Change Audio 'Stop' method so it doesn't click

I feel that the Stop action of the Audio object isn't quite fit for games because it abruptly cuts off the waveform, causing an undesirable click or pop [example], at least when using the .m4a format. Most audio players and editors use inperceptible micro-fades to prevent/reduce this artifact. If possible, I think Construct 2 should do the same.

Unless you work with audio a lot, the 'click' hardly feels like the natural result of stopping a sound. It's not what is expected of a Stop action. The click is literally CREATED when you cut off the audio, because the waveform does a straight line back to 0. Why should something be added to the audio that wasn't there originally? And what is the use of this inconsistent sound in games? That's why I think micro-fading the audio is like a higher quality 'stop algorithm' with more natural, useable results. The final thing you hear is the original sound itself, rather than a sharp click. That seems much closer to the behavior we expect.

In any case, if the current method cannot be changed, may I suggest creating a 'Fade Stop' action as an alternative? This would fade the audio down to 0 through a specified number of milliseconds before actually stopping the sample. This I feel would have more uses in games over the current stop method and I believe it would be a worthwhile addition to the official Audio object. What say?

Why not make your own fade in events?

In case the example is hard to get to, I've attached it to this post.

newt Events update per frame, whereas the "micro-fading" I'm talking about has to happen in 2ms. Let me clarify that the point is to prevent the high-frequency click that occurs when a sound is stopped midway through, not to modify the original sound in a perceptible way. It's not a "fade" so much as it is a better algorithm for stopping the sound. The current algorithm basically adds a click to the sound. The one I'm suggesting leaves it as it is, not to mention that it indeed stops well before the next frame. Which one behaves more as expected?

Naturally, I feel the native Stop action should have this 'smoothening' behavior by default, because I can't imagine a scenario where this inconsistent click would be desired in a game, can you? As it stands, it feels more like a bug. It's only if there are reasons to leave the method as it is that I would suggest a "Fade Stop" action as an alternative to allow people to avoid those pesky clicks.

I read a post from 2010 from someone encountering this issue in Unity (I wonder if it is fixed now). The solution suggested was to write a routine that fades it out in 1/10 of a frame. That's exactly what I think Construct 2 should do natively, because it's the only way people want to use 'Stop'. To do that in Construct 2 right now, I would have to modify the Audio object (and I would do a sloppy job of it), and this will put me out of sync with future updates.

If this is as common an issue as the person in the post suggested, and if people everywhere end up writing their own micro-fade routines to fix it, why not just make it native functionality in Construct 2? To me I think the Audio: Stop method is less useful if it doesn't behave the way most people would like it to. How many people expect there to be a click when they stop their audio? That's not what 'Stop' is supposed to do in games!

newt, it sounds like he's suggesting a change to an already implemented action. If it is, in fact, better sounding this way, why should he have to do it?

Anyway, I'd like to hear more input on this.

This worked fine for me.

[attachment=0:3uzg48i8][/attachment:3uzg48i8]

newt That workaround works fine for this demo, but not in more practical applications (see below). While workarounds may work in certain cases, my intent with this post is to explore whether 'Audio > Stop' should do it on its own. Why so adamant on finding an event-based solution when this is something that should work right out of the box? Between a stop that clicks, and one that doesn't, which one falls more in line with the expectations of the game developer? Which one is more useable? It's obvious that the 'click' noise is unwanted and unexpected. Shouldn't we consider this suggestion as a way to improve Construct 2 functionality?

In the case of the demo, the workaround you posted is simple and manageable. But now consider a more practical use of Audio > Stop: preventing the overlap of similar/clashing sounds, like collectibles. Imagine Mario running through a bunch of closely spaced coins. "Ding ding...d..d.d..d..d...ding" is what it should sound like, rather than "Ding ding...d *pop* d *click* d *pop* etc." That sounds unpolished, glitchy and unprofessional. Granted, for many sounds the popping is subtle and big pops only happen once in a while. But that inconsistency alone is troubling.

Check the event sheet in the attached .capx. The solution that would ideally work is to simply stop the previous sound, then play a new one. The workaround you posted almost works, but it plays the sound 0.02 seconds late because of the Wait, which is not the desired game experience.

The workaround that actually works requires a variable that toggles between two values. Now we can stop the previous sound in a neat way but immediately start the next sound. Kinda ugly, but it works. But now let's say I have different kinds of collectibles. It complicates things a bit more, and ends up obfuscating the events more too. And really, all we want is to stop a sound without that unwanted click.

So now consider my main points:

• Audio > Stop doesn't imply anything about audio 'clicking'. It is most certaintly unexpected behavior. The click is usually an unwanted addition to the sound.
• It is hard to imagine a case where someone would desire the 'click', especially because its very inconsistent, and shouldn't be there in the first place.
• Workarounds using events are not straightforward. The cleanest approach is to modify the Audio object with a micro-fade.

Does the above not seem to you a compelling enough case to at least consider changing the 'Audio > Stop' action? I would like to at least discuss the feasibility and implications of changing it. I understand that sometimes people post suggestions when they want something very specific to work in their game. This is not the case with my suggestion. This is a somewhat common issue in multimedia work. In music production, for example, when a sample is chopped out of a wave, a slight attack and decay will be added to get rid of the clicks. No one wants the clicks! I don't think game development is any different.

OK, but there are a few things you also need to think about.

First is that what you are looking for is a change on how the sound is rendered, by the system, not a change in the C2 engine, or better described as a hack.

Second, the kind of timing precision you want isn't there, especially on mobile. You'll be lucky to get 0.1 ms.

Thirdly, this is why we have polyphony.

Html5 is just now barely suited to game dev, sound manipulation is still a bit off into the future. To be honest, what we have is pretty damn good considering what the api covers. I think sound engineering was one of Ashleys majors, so that might have something to do with that.

Also theres nothing wrong with using an even shorter sound for that type of situation.

Anyway, it may very well be that he can change the system to accommodate that change, however my opinion is that like it or not, it is a "feature", and I don't like getting rid of them, as you never know when they will be exploitable.

Ah cool, thanks for this perspective. You're right that what we have is astounding already, quite a feat. As a C2 fan, I merely seek to help improve the engine, though obviously I have very little knowledge of its inner workings. That's where discussion helps me.

First is that what you are looking for is a change on how the sound is rendered, by the system, not a change in the C2 engine, or better described as a hack.

I think I get where you're going, but I don't see it as a change in how the sound is rendered. In a C2 game, if you were to fade an object out before destroying it, is that a change in how objects are destroyed? You are merely using the system how it's supposed to be used to achieve a result more useable within the scope of your product. Put another way, just because there is a System.StopAudio() doesn't mean that MyGameEngine.StopAudio() is restricted to solely calling System.StopAudio(). There are specific needs the game engine has, among which are aesthetically pleasing audio playback. I am suggesting a change in C2's Audio > Stop, not the system's core implementation of audio rendering.

[quote:2u1jdq9c]Second, the kind of timing precision you want isn't there, especially on mobile. You'll be lucky to get 0.1 ms.

Yeah, I didn't think of this too much. "0.1 ms" precision? That doesn't sound too bad for a fade-out that must occur in less than a frame of 16ms. Honestly, anything to reduce the harshness of the click is beneficial I feel.

[quote:2u1jdq9c]Thirdly, this is why we have polyphony.

Haha, yeah but there is still a definite need in games to stop certain sound samples from overlapping, just as there is a need to prevent certain images from overlapping. You wouldn't say "that's why we have layers". There is obviously such a thing as aesthetics, and it can apply to audio just as much as it can to visuals.

[quote:2u1jdq9c]Also theres nothing wrong with using an even shorter sound for that type of situation.

The sound in the demo was exaggerated to demonstrate the effect. Consider a real game like Super Mario World when he's flying through a bunch of coins. Look at how neatly the sound effect repeats for each coin, how it cuts off the previous one. Even if they had the full polyphonic capabilities of today they wouldn't have let them play together. Letting those sounds play together creates this muddy kind of reverb-y, sloppy sound, characteristic of amateur fan-made platformers. It's very disgusting. A shorter sound is not the solution, or the coin wouldn't have the rewarding effect it does when you get one. I mean, come on, unless you're just a programmer, you know that game design and development is art! And artists are picky people. Lots of subtleties to think about. The engine shouldn't require us to make compromises on something that can be fixed.

Anyway, I'm up way past my bedtime. Perhaps the -100db solution is fine. But hopefully this is something to think about, because there is basically no reason I see for someone wanting the risk of that click when they call Audio > Stop.